<!DOCTYPE html>
<html lang="en"><head>
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
   <title>
 HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)
</title><script type="application/javascript">
function getMeta(rfcno, container) {

  var xhr = new XMLHttpRequest();
  xhr.open("GET", "https://tools.ietf.org/draft/rfc" + rfcno + "/state.xml", true);
  xhr.onload = function (e) {
    if (xhr.readyState === 4) {
      if (xhr.status === 200) {
        var doc = xhr.responseXML;
        var info = getChildByName(doc.documentElement, "info");
  
        var cont = document.getElementById(container);
        // empty the container
        while (cont.firstChild) {
          cont.removeChild(myNode.firstChild);
        }      
  
        var c = getChildByName(info, "stdstatus");
        if (c !== null) {
          var bld = newElementWithText("b", c.textContent);
          cont.appendChild(bld);
        }
  
        c = getChildByName(info, "updatedby");
        if (c !== null) {
          cont.appendChild(newElement("br"));
          cont.appendChild(newText("Updated by: "));
          appendRfcLinks(cont, c.textContent);
        }
  
        c = getChildByName(info, "obsoletedby");
        if (c !== null) {
          cont.appendChild(newElement("br"));
          cont.appendChild(newText("Obsoleted by: "));
          appendRfcLinks(cont, c.textContent);
        }
        
        c = getChildByName(info, "errata");
        if (c !== null) {
          cont.appendChild(newElement("br"));
          var link = newElementWithText("a", "errata");
          link.setAttribute("href", "http://www.rfc-editor.org/errata_search.php?rfc=" + rfcno);
          var errata = newElementWithText("i", "This document has ");
          errata.appendChild(link);
          errata.appendChild(newText("."));
          cont.appendChild(errata);
        }

        cont.style.display = "block";
      } else {
        console.error(xhr.statusText);
      }
    }
  };
  xhr.onerror = function (e) {
    console.error(xhr.status + " " + xhr.statusText);
  };
  xhr.send(null);
}

// DOM helpers
function newElement(name) {
  return document.createElement(name);
}
function newElementWithText(name, txt) {
  var e = document.createElement(name);
  e.appendChild(newText(txt));
  return e;
}
function newText(text) {
  return document.createTextNode(text);
}

function getChildByName(parent, name) {
  if (parent === null) {
    return null;
  }
  else {
    for (var c = parent.firstChild; c !== null; c = c.nextSibling) {
      if (name == c.nodeName) {
        return c;
      }
    }
    return null;
  }
}

function appendRfcLinks(parent, text) {
  var updates = text.split(",");
  for (var i = 0; i < updates.length; i++) {
    var rfc = updates[i].trim();
    if (rfc.substring(0, 3) == "rfc") {
      var link = newElement("a");
      link.setAttribute("href", "http://tools.ietf.org/html/" + rfc);
      link.appendChild(newText(rfc.substring(3)));
      parent.appendChild(link);
    } else {
      parent.appendChild(newText(rfc));
    }
    if (i != updates.length - 1) {
      parent.appendChild(newText(", "));
    }
  }
}
</script><script type="application/javascript">
function anchorRewrite() {
  map = { "Simple-ref": "simple-ref", "activelock": "ELEMENT_activelock", "allprop": "ELEMENT_allprop", "collection": "ELEMENT_collection", "depth": "ELEMENT_depth", "error": "ELEMENT_error", "exclusive": "ELEMENT_exclusive", "href": "ELEMENT_href", "include": "ELEMENT_include", "location": "ELEMENT_location", "lockentry": "ELEMENT_lockentry", "lockinfo": "ELEMENT_lockinfo", "lockroot": "ELEMENT_lockroot", "lockscope": "ELEMENT_lockscope", "locktoken": "ELEMENT_locktoken", "locktype": "ELEMENT_locktype", "multistatus": "ELEMENT_multistatus", "owner": "ELEMENT_owner", "prop": "ELEMENT_prop", "propertyupdate": "ELEMENT_propertyupdate", "propfind": "ELEMENT_propfind", "propname": "ELEMENT_propname", "propstat": "ELEMENT_propstat", "remove": "ELEMENT_remove", "response": "ELEMENT_response", "responsedescription": "ELEMENT_responsedescription", "set": "ELEMENT_set", "shared": "ELEMENT_shared", "status": "ELEMENT_status", "timeout": "ELEMENT_timeout", "write": "ELEMENT_write", "creationdate": "PROPERTY_creationdate", "displayname": "PROPERTY_displayname", "getcontentlanguage": "PROPERTY_getcontentlanguage", "getcontentlength": "PROPERTY_getcontentlength", "getcontenttype": "PROPERTY_getcontenttype", "getetag": "PROPERTY_getetag", "getlastmodified": "PROPERTY_getlastmodified", "lockdiscovery": "PROPERTY_lockdiscovery", "resourcetype": "PROPERTY_resourcetype", "supportedlock": "PROPERTY_supportedlock"};
  if (window.location.hash.length >= 1) {
    var fragid = window.location.hash.substr(1);
    if (fragid) {
      if (! document.getElementById(fragid)) {
        var prefix = "rfc.";
        var mapped = map[fragid];
        if (mapped) {
          window.location.hash = mapped;
        } else if (fragid.indexOf("section-") == 0) {
          window.location.hash = prefix + "section." + fragid.substring(8);
        } else if (fragid.indexOf("appendix-") == 0) {
          window.location.hash = prefix + "section." + fragid.substring(9);
        } else if (fragid.indexOf("s-") == 0) {
          window.location.hash = prefix + "section." + fragid.substring(2);
        } else if (fragid.indexOf("p-") == 0) {
          var r = fragid.substring(2);
          var p = r.indexOf("-");
          if (p >= 0) {
            window.location.hash = prefix + "section." + r.substring(0, p) + ".p." + r.substring(p + 1);
          }
        }
      }
    }  
  }
}
window.addEventListener('hashchange', anchorRewrite);
window.addEventListener('DOMContentLoaded', anchorRewrite);
</script><style type="text/css" title="Xml2Rfc (sans serif)">
a {
  text-decoration: none;
}
a.smpl {
  color: black;
}
a:hover {
  text-decoration: underline;
}
a:active {
  text-decoration: underline;
}
address {
  margin-top: 1em;
  margin-left: 2em;
  font-style: normal;
}
body {
  color: black;
  font-family: cambria, georgia, serif;
  font-size: 12pt;
  margin: 2em auto;
  max-width: 1000px;
}
samp, span.tt, code, pre {
  font-family: consolas, monaco, monospace;
}
cite {
  font-style: normal;
}
dl {
  margin-left: 2em;
}
dl > dt {
  float: left;
  margin-right: 1em;
}
dl.nohang > dt {
  float: none;
}
dl > dd {
  margin-bottom: .5em;
}
dl.compact > dd {
  margin-bottom: .0em;
}
dl > dd > dl {
  margin-top: 0.5em;
}
ul.empty {
  list-style-type: none;
}
ul.empty li {
  margin-top: .5em;
}
dl p {
  margin-left: 0em;
}
dl.reference > dt {
  font-weight: bold;
}
dl.reference > dd {
  margin-left: 6em;
}
h1 {
  color: green;
  font-size: 150%;
  line-height: 18pt;
  font-weight: bold;
  text-align: center;
  margin-top: 36pt;
  margin-bottom: 0pt;
}
h2 {
  font-size: 130%;
  line-height: 21pt;
  page-break-after: avoid;
}
h2.np {
  page-break-before: always;
}
h3 {
  font-size: 120%;
  line-height: 15pt;
  page-break-after: avoid;
}
h4 {
  font-size: 110%;
  page-break-after: avoid;
}
h5, h6 {
  page-break-after: avoid;
}
h1 a, h2 a, h3 a, h4 a, h5 a, h6 a {
  color: black;
}
img {
  margin-left: 3em;
}
li {
  margin-left: 2em;
}
ol {
  margin-left: 2em;
}
ol.la {
  list-style-type: lower-alpha;
}
ol.ua {
  list-style-type: upper-alpha;
}
ol p {
  margin-left: 0em;
}
p {
  margin-left: 2em;
}
pre {
  font-size: 11pt;
  margin-left: 3em;
  background-color: lightyellow;
  padding: .25em;
  page-break-inside: avoid;
}
pre.text2 {
  border-style: dotted;
  border-width: 1px;
  background-color: #f0f0f0;
}
pre.inline {
  background-color: white;
  padding: 0em;
  page-break-inside: auto;
}
pre.text {
  border-style: dotted;
  border-width: 1px;
  background-color: #f8f8f8;
}
pre.drawing {
  border-style: solid;
  border-width: 1px;
  background-color: #f8f8f8;
  padding: 2em;
}
sup {
  font-size: 60%;
}
table {
  margin-left: 2em;
}
div.tt {
  margin-left: 2em;
} 
table.tt {
  border-collapse: collapse;
  border-color: gray;
  border-spacing: 0; 
  vertical-align: top;
 }
table.tt th {
  border-color: gray;
  padding: 3px;
}
table.tt td {
  border-color: gray;
  padding: 3px;
}
table.all {
  border-style: solid;
  border-width: 2px;
}
table.full {
  border-style: solid;
  border-width: 2px;
}
table.tt td {
  vertical-align: top;
}
table.all td {
  border-style: solid;
  border-width: 1px;
}
table.full td {
  border-style: none solid;
  border-width: 1px;
}
table.tt th {
  vertical-align: top;
}
table.all th {
  border-style: solid;
  border-width: 1px;
}
table.full th {
  border-style: solid;
  border-width: 1px 1px 2px 1px;
}
table.headers th {
  border-style: none none solid none;
  border-width: 2px;
}
table.tleft {
  margin-right: auto;
}
table.tright {
  margin-left: auto;
}
table.tcenter {
  margin-left: auto;
  margin-right: auto;
}
caption {
  caption-side: bottom;
  font-weight: bold;
  font-size: 10pt;
  margin-top: .5em;
}

table.header {
  border-spacing: 1px;
  width: 95%;
  font-size: 11pt;
  color: white;
}
td.top {
  vertical-align: top;
}
td.topnowrap {
  vertical-align: top;
  white-space: nowrap;
}
table.header td {
  background-color: gray;
  width: 50%;
}
table.header a {
  color: white;
}
ul.toc, ul.toc ul {
  list-style: none;
  margin-left: 1.5em;
  padding-left: 0em;
}
ul.toc li {
  line-height: 150%;
  font-weight: bold;
  margin-left: 0em;
}
ul.toc li li {
  line-height: normal;
  font-weight: normal;
  font-size: 11pt;
  margin-left: 0em;
}
li.excluded {
  font-size: 0pt;
}
ul p {
  margin-left: 0em;
}
.filename, h1, h2, h3, h4 {
  font-family: candara, calibri, segoe, optima, arial, sans-serif;
}
ul.ind, ul.ind ul {
  list-style: none;
  margin-left: 1.5em;
  padding-left: 0em;
  page-break-before: avoid;
}
ul.ind li {
  font-weight: bold;
  line-height: 200%;
  margin-left: 0em;
}
ul.ind li li {
  font-weight: normal;
  line-height: 150%;
  margin-left: 0em;
}
.avoidbreakinside {
  page-break-inside: avoid;
}
.avoidbreakafter {
  page-break-after: avoid;
}
.bcp14 {
  font-style: normal;
  text-transform: lowercase;
  font-variant: small-caps;
}
.comment {
  background-color: yellow;
}
.center {
  text-align: center;
}
.error {
  color: red;
  font-style: italic;
  font-weight: bold;
}
.figure {
  font-weight: bold;
  text-align: center;
  font-size: 10pt;
}
.filename {
  color: #333333;
  font-size: 112%;
  font-weight: bold;
  line-height: 21pt;
  text-align: center;
  margin-top: 0pt;
}
.fn {
  font-weight: bold;
}
.left {
  text-align: left;
}
.right {
  text-align: right;
}
.warning {
  font-size: 130%;
  background-color: yellow;
}
.self {
    color: #999999;
    margin-left: .3em;
    text-decoration: none;
    visibility: hidden;
    -webkit-user-select: none; 
    -moz-user-select: none;
    -ms-user-select: none;
}
.self:hover {
    text-decoration: none;
}
p:hover .self {
    visibility: visible;
}
.docstatus {
  border: 1px solid black;
  display: none;
  float: right;
  margin: 2em;
  padding: 1em;
}

@media screen {
  pre.text, pre.text2 {
    width: 69em;
  }
}

@media print {
  .noprint {
    display: none;
  }

  a {
    color: black;
    text-decoration: none;
  }

  table.header {
    width: 90%;
  }

  td.header {
    width: 50%;
    color: black;
    background-color: white;
    vertical-align: top;
    font-size: 110%;
  }

  ul.toc a:last-child::after {
    content: leader('.') target-counter(attr(href), page);
  }

  ul.ind li li a {
    content: target-counter(attr(href), page);
  }

  pre {
    font-size: 10pt;
  }

  .print2col {
    column-count: 2;
    -moz-column-count: 2;
    column-fill: auto;
  }
}
@page {
  @top-left {
       content: "RFC 4918";
  }
  @top-right {
       content: "June 2007";
  }
  @top-center {
       content: "WebDAV";
  }
  @bottom-left {
       content: "Dusseault";
  }
  @bottom-center {
       content: "Standards Track";
  }
  @bottom-right {
       content: "[Page " counter(page) "]";
  }
}
@page:first {
    @top-left {
      content: normal;
    }
    @top-right {
      content: normal;
    }
    @top-center {
      content: normal;
    }
}
</style><link rel="Contents" href="#rfc.toc"><link rel="Author" href="#rfc.authors"><link rel="Copyright" href="#rfc.copyright"><link rel="Index" href="#rfc.index"><link rel="Chapter" title="1 Introduction" href="#rfc.section.1"><link rel="Chapter" title="2 Notational Conventions" href="#rfc.section.2"><link rel="Chapter" title="3 Terminology" href="#rfc.section.3"><link rel="Chapter" title="4 Data Model for Resource Properties" href="#rfc.section.4"><link rel="Chapter" title="5 Collections of Web Resources" href="#rfc.section.5"><link rel="Chapter" title="6 Locking" href="#rfc.section.6"><link rel="Chapter" title="7 Write Lock" href="#rfc.section.7"><link rel="Chapter" title="8 General Request and Response Handling" href="#rfc.section.8"><link rel="Chapter" title="9 HTTP Methods for Distributed Authoring" href="#rfc.section.9"><link rel="Chapter" title="10 HTTP Headers for Distributed Authoring" href="#rfc.section.10"><link rel="Chapter" title="11 Status Code Extensions to HTTP/1.1" href="#rfc.section.11"><link rel="Chapter" title="12 Use of HTTP Status Codes" href="#rfc.section.12"><link rel="Chapter" title="13 Multi-Status Response" href="#rfc.section.13"><link rel="Chapter" title="14 XML Element Definitions" href="#rfc.section.14"><link rel="Chapter" title="15 DAV Properties" href="#rfc.section.15"><link rel="Chapter" title="16 Precondition/Postcondition XML Elements" href="#rfc.section.16"><link rel="Chapter" title="17 XML Extensibility in DAV" href="#rfc.section.17"><link rel="Chapter" title="18 DAV Compliance Classes" href="#rfc.section.18"><link rel="Chapter" title="19 Internationalization Considerations" href="#rfc.section.19"><link rel="Chapter" title="20 Security Considerations" href="#rfc.section.20"><link rel="Chapter" title="21 IANA Considerations" href="#rfc.section.21"><link rel="Chapter" title="22 Acknowledgements" href="#rfc.section.22"><link rel="Chapter" title="23 Contributors to This Specification" href="#rfc.section.23"><link rel="Chapter" title="24 Authors of RFC 2518" href="#rfc.section.24"><link rel="Chapter" href="#rfc.section.25" title="25 References"><link rel="Appendix" title="A Notes on Processing XML Elements" href="#rfc.section.A"><link rel="Appendix" title="B Notes on HTTP Client Compatibility" href="#rfc.section.B"><link rel="Appendix" title="C The 'opaquelocktoken' Scheme and URIs" href="#rfc.section.C"><link rel="Appendix" title="D Lock-null Resources" href="#rfc.section.D"><link rel="Appendix" title="E Guidance for Clients Desiring to Authenticate" href="#rfc.section.E"><link rel="Appendix" title="F Summary of Changes from RFC 2518" href="#rfc.section.F"><link rel="Alternate" title="Authoritative ASCII Version" href="http://www.ietf.org/rfc/rfc4918.txt"><link rel="Help" title="RFC-Editor's Status Page" href="http://www.rfc-editor.org/info/rfc4918"><link rel="Help" title="Additional Information on tools.ietf.org" href="http://tools.ietf.org/html/rfc4918"><meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.840, 2016/11/16 05:32:10, XSLT vendor: SAXON 6.5.5 from Michael Kay http://saxon.sf.net/"><meta name="keywords" content="webdav, http, authoring, web, locks, propfind, proppatch, mkcol"><link rel="schema.dcterms" href="http://purl.org/dc/terms/"><meta name="dcterms.creator" content="Dusseault, L.M."><meta name="dcterms.identifier" content="urn:ietf:rfc:4918"><meta name="dcterms.issued" content="2007-06"><meta name="dct.replaces" content="urn:ietf:rfc:2518"><meta name="dcterms.abstract" content="Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance). RFC 2518 was published in February 1999, and this specification obsoletes RFC 2518 with minor revisions mostly due to interoperability experience."><meta name="dcterms.isPartOf" content="urn:issn:2070-1721"><meta name="description" content="Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance). RFC 2518 was published in February 1999, and this specification obsoletes RFC 2518 with minor revisions mostly due to interoperability experience."></head><body onload='getMeta(4918,"rfc.meta");'><header><table class="header" id="rfc.headerblock"><tbody><tr><td class="left">Network Working Group</td><td class="right">L. Dusseault, Editor</td></tr><tr><td class="left">Request for Comments: 4918</td><td class="right">CommerceNet</td></tr><tr><td class="left">Obsoletes: <a href="https://tools.ietf.org/html/rfc2518">2518</a></td><td class="right">June 2007</td></tr><tr><td class="left">Category: Standards Track</td><td class="right"></td></tr></tbody></table><div id="rfc.title"><h1>HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)</h1></div></header><div id="rfc.meta" class="docstatus" style="display: block;"><b>PROPOSED STANDARD</b><br>Updated by: <a href="http://tools.ietf.org/html/rfc5689">5689</a><br><i>This document has <a href="http://www.rfc-editor.org/errata_search.php?rfc=4918">errata</a>.</i></div><section id="rfc.status"><h2><a href="#rfc.status">Status of This Memo</a></h2><p>This
 document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 
improvements. Please refer to the current edition of the “Internet 
Official Protocol Standards” (STD 1) for the standardization state and 
status of this protocol. Distribution of this memo is unlimited.</p></section><section id="rfc.copyrightnotice"><h2><a href="#rfc.copyrightnotice">Copyright Notice</a></h2><p>Copyright © The IETF Trust (2007). All Rights Reserved.</p></section><section id="rfc.abstract"><h2><a href="#rfc.abstract">Abstract</a></h2><p>Web
 Distributed Authoring and Versioning (WebDAV) consists of a set of 
methods, headers, and content-types ancillary to HTTP/1.1 for the 
management of resource properties, creation and management of resource 
collections, URL namespace manipulation, and resource locking (collision
 avoidance).</p><p>RFC 2518 was published in February 1999, and this 
specification obsoletes RFC 2518 with minor revisions mostly due to 
interoperability experience.</p></section><hr class="noprint"><nav id="rfc.toc"><h2 class="np"><a href="#rfc.toc">Table of Contents</a></h2><ul class="toc"><li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#intro">Introduction</a></li><li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2">Notational Conventions</a></li><li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3">Terminology</a></li><li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#data.model.for.resource.properties">Data Model for Resource Properties</a><ul><li><a href="#rfc.section.4.1">4.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.1">The Resource Property Model</a></li><li><a href="#rfc.section.4.2">4.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.2">Properties and HTTP Headers</a></li><li><a href="#rfc.section.4.3">4.3</a>&nbsp;&nbsp;&nbsp;<a href="#property_values">Property Values</a><ul><li><a href="#rfc.section.4.3.1">4.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.3.1">Example - Property with Mixed Content</a></li></ul></li><li><a href="#rfc.section.4.4">4.4</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.4">Property Names</a></li><li><a href="#rfc.section.4.5">4.5</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.5">Source Resources and Output Resources</a></li></ul></li><li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#collections.of.web.resources">Collections of Web Resources</a><ul><li><a href="#rfc.section.5.1">5.1</a>&nbsp;&nbsp;&nbsp;<a href="#http.url.namespace.model">HTTP URL Namespace Model</a></li><li><a href="#rfc.section.5.2">5.2</a>&nbsp;&nbsp;&nbsp;<a href="#collection.resources">Collection Resources</a></li></ul></li><li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#locking">Locking</a><ul><li><a href="#rfc.section.6.1">6.1</a>&nbsp;&nbsp;&nbsp;<a href="#lock-model">Lock Model</a></li><li><a href="#rfc.section.6.2">6.2</a>&nbsp;&nbsp;&nbsp;<a href="#exclusive-lock">Exclusive vs. Shared Locks</a></li><li><a href="#rfc.section.6.3">6.3</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.6.3">Required Support</a></li><li><a href="#rfc.section.6.4">6.4</a>&nbsp;&nbsp;&nbsp;<a href="#lock-creator">Lock Creator and Privileges</a></li><li><a href="#rfc.section.6.5">6.5</a>&nbsp;&nbsp;&nbsp;<a href="#lock-tokens">Lock Tokens</a></li><li><a href="#rfc.section.6.6">6.6</a>&nbsp;&nbsp;&nbsp;<a href="#lock-timeout">Lock Timeout</a></li><li><a href="#rfc.section.6.7">6.7</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.6.7">Lock Capability Discovery</a></li><li><a href="#rfc.section.6.8">6.8</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.6.8">Active Lock Discovery</a></li></ul></li><li><a href="#rfc.section.7">7.</a>&nbsp;&nbsp;&nbsp;<a href="#write-lock">Write Lock</a><ul><li><a href="#rfc.section.7.1">7.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.7.1">Write Locks and Properties</a></li><li><a href="#rfc.section.7.2">7.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.7.2">Avoiding Lost Updates</a></li><li><a href="#rfc.section.7.3">7.3</a>&nbsp;&nbsp;&nbsp;<a href="#lock-unmapped-urls">Write Locks and Unmapped URLs</a></li><li><a href="#rfc.section.7.4">7.4</a>&nbsp;&nbsp;&nbsp;<a href="#write.locks.and.collections">Write Locks and Collections</a></li><li><a href="#rfc.section.7.5">7.5</a>&nbsp;&nbsp;&nbsp;<a href="#write.locks.and.the.if.request.header">Write Locks and the If Request Header</a><ul><li><a href="#rfc.section.7.5.1">7.5.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.7.5.1">Example - Write Lock and COPY</a></li><li><a href="#rfc.section.7.5.2">7.5.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.7.5.2">Example - Deleting a Member of a Locked Collection</a></li></ul></li><li><a href="#rfc.section.7.6">7.6</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.7.6">Write Locks and COPY/MOVE</a></li><li><a href="#rfc.section.7.7">7.7</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.7.7">Refreshing Write Locks</a></li></ul></li><li><a href="#rfc.section.8">8.</a>&nbsp;&nbsp;&nbsp;<a href="#response-handling">General Request and Response Handling</a><ul><li><a href="#rfc.section.8.1">8.1</a>&nbsp;&nbsp;&nbsp;<a href="#error-precedence">Precedence in Error Handling</a></li><li><a href="#rfc.section.8.2">8.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.2">Use of XML</a></li><li><a href="#rfc.section.8.3">8.3</a>&nbsp;&nbsp;&nbsp;<a href="#url-handling">URL Handling</a><ul><li><a href="#rfc.section.8.3.1">8.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.3.1">Example - Correct URL Handling</a></li></ul></li><li><a href="#rfc.section.8.4">8.4</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.4">Required Bodies in Requests</a></li><li><a href="#rfc.section.8.5">8.5</a>&nbsp;&nbsp;&nbsp;<a href="#http-headers">HTTP Headers for Use in WebDAV</a></li><li><a href="#rfc.section.8.6">8.6</a>&nbsp;&nbsp;&nbsp;<a href="#etag">ETag</a></li><li><a href="#rfc.section.8.7">8.7</a>&nbsp;&nbsp;&nbsp;<a href="#including.error.reponse.bodies">Including Error Response Bodies</a></li><li><a href="#rfc.section.8.8">8.8</a>&nbsp;&nbsp;&nbsp;<a href="#cache-control">Impact of Namespace Operations on Cache Validators</a></li></ul></li><li><a href="#rfc.section.9">9.</a>&nbsp;&nbsp;&nbsp;<a href="#http.methods.for.distributed.authoring">HTTP Methods for Distributed Authoring</a><ul><li><a href="#rfc.section.9.1">9.1</a>&nbsp;&nbsp;&nbsp;<a href="#METHOD_PROPFIND">PROPFIND Method</a><ul><li><a href="#rfc.section.9.1.1">9.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.1.1">PROPFIND Status Codes</a></li><li><a href="#rfc.section.9.1.2">9.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#PROPFIND-multistatus">Status Codes for Use in 'propstat' Element</a></li><li><a href="#rfc.section.9.1.3">9.1.3</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.1.3">Example - Retrieving Named Properties</a></li><li><a href="#rfc.section.9.1.4">9.1.4</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.1.4">Example - Using 'propname' to Retrieve All Property Names</a></li><li><a href="#rfc.section.9.1.5">9.1.5</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.1.5">Example - Using So-called 'allprop'</a></li><li><a href="#rfc.section.9.1.6">9.1.6</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.1.6">Example - Using 'allprop' with 'include'</a></li></ul></li><li><a href="#rfc.section.9.2">9.2</a>&nbsp;&nbsp;&nbsp;<a href="#METHOD_PROPPATCH">PROPPATCH Method</a><ul><li><a href="#rfc.section.9.2.1">9.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#PROPPATCH-status">Status Codes for Use in 'propstat' Element</a></li><li><a href="#rfc.section.9.2.2">9.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.2.2">Example - PROPPATCH</a></li></ul></li><li><a href="#rfc.section.9.3">9.3</a>&nbsp;&nbsp;&nbsp;<a href="#METHOD_MKCOL">MKCOL Method</a><ul><li><a href="#rfc.section.9.3.1">9.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.3.1">MKCOL Status Codes</a></li><li><a href="#rfc.section.9.3.2">9.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.3.2">Example - MKCOL</a></li></ul></li><li><a href="#rfc.section.9.4">9.4</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.4">GET, HEAD for Collections</a></li><li><a href="#rfc.section.9.5">9.5</a>&nbsp;&nbsp;&nbsp;<a href="#METHOD_POST">POST for Collections</a></li><li><a href="#rfc.section.9.6">9.6</a>&nbsp;&nbsp;&nbsp;<a href="#METHOD_DELETE">DELETE Requirements</a><ul><li><a href="#rfc.section.9.6.1">9.6.1</a>&nbsp;&nbsp;&nbsp;<a href="#delete-collections">DELETE for Collections</a></li><li><a href="#rfc.section.9.6.2">9.6.2</a>&nbsp;&nbsp;&nbsp;<a href="#DELETE-example">Example - DELETE</a></li></ul></li><li><a href="#rfc.section.9.7">9.7</a>&nbsp;&nbsp;&nbsp;<a href="#METHOD_PUT">PUT Requirements</a><ul><li><a href="#rfc.section.9.7.1">9.7.1</a>&nbsp;&nbsp;&nbsp;<a href="#put-resources">PUT for Non-Collection Resources</a></li><li><a href="#rfc.section.9.7.2">9.7.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.7.2">PUT for Collections</a></li></ul></li><li><a href="#rfc.section.9.8">9.8</a>&nbsp;&nbsp;&nbsp;<a href="#METHOD_COPY">COPY Method</a><ul><li><a href="#rfc.section.9.8.1">9.8.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.8.1">COPY for Non-collection Resources</a></li><li><a href="#rfc.section.9.8.2">9.8.2</a>&nbsp;&nbsp;&nbsp;<a href="#copy.for.properties">COPY for Properties</a></li><li><a href="#rfc.section.9.8.3">9.8.3</a>&nbsp;&nbsp;&nbsp;<a href="#copy.for.collections">COPY for Collections</a></li><li><a href="#rfc.section.9.8.4">9.8.4</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.8.4">COPY and Overwriting Destination Resources</a></li><li><a href="#rfc.section.9.8.5">9.8.5</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.8.5">Status Codes</a></li><li><a href="#rfc.section.9.8.6">9.8.6</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.8.6">Example - COPY with Overwrite</a></li><li><a href="#rfc.section.9.8.7">9.8.7</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.8.7">Example - COPY with No Overwrite</a></li><li><a href="#rfc.section.9.8.8">9.8.8</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.8.8">Example - COPY of a Collection</a></li></ul></li><li><a href="#rfc.section.9.9">9.9</a>&nbsp;&nbsp;&nbsp;<a href="#METHOD_MOVE">MOVE Method</a><ul><li><a href="#rfc.section.9.9.1">9.9.1</a>&nbsp;&nbsp;&nbsp;<a href="#move-properties">MOVE for Properties</a></li><li><a href="#rfc.section.9.9.2">9.9.2</a>&nbsp;&nbsp;&nbsp;<a href="#move-collections">MOVE for Collections</a></li><li><a href="#rfc.section.9.9.3">9.9.3</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.9.3">MOVE and the Overwrite Header</a></li><li><a href="#rfc.section.9.9.4">9.9.4</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.9.4">Status Codes</a></li><li><a href="#rfc.section.9.9.5">9.9.5</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.9.5">Example - MOVE of a Non-Collection</a></li><li><a href="#rfc.section.9.9.6">9.9.6</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.9.6">Example - MOVE of a Collection</a></li></ul></li><li><a href="#rfc.section.9.10">9.10</a>&nbsp;&nbsp;&nbsp;<a href="#METHOD_LOCK">LOCK Method</a><ul><li><a href="#rfc.section.9.10.1">9.10.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.10.1">Creating a Lock on an Existing Resource</a></li><li><a href="#rfc.section.9.10.2">9.10.2</a>&nbsp;&nbsp;&nbsp;<a href="#refreshing-locks">Refreshing Locks</a></li><li><a href="#rfc.section.9.10.3">9.10.3</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.10.3">Depth and Locking</a></li><li><a href="#rfc.section.9.10.4">9.10.4</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.10.4">Locking Unmapped URLs</a></li><li><a href="#rfc.section.9.10.5">9.10.5</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.10.5">Lock Compatibility Table</a></li><li><a href="#rfc.section.9.10.6">9.10.6</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.10.6">LOCK Responses</a></li><li><a href="#rfc.section.9.10.7">9.10.7</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.10.7">Example - Simple Lock Request</a></li><li><a href="#rfc.section.9.10.8">9.10.8</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.10.8">Example - Refreshing a Write Lock</a></li><li><a href="#rfc.section.9.10.9">9.10.9</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.10.9">Example - Multi-Resource Lock Request</a></li></ul></li><li><a href="#rfc.section.9.11">9.11</a>&nbsp;&nbsp;&nbsp;<a href="#METHOD_UNLOCK">UNLOCK Method</a><ul><li><a href="#rfc.section.9.11.1">9.11.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.11.1">Status Codes</a></li><li><a href="#rfc.section.9.11.2">9.11.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.11.2">Example - UNLOCK</a></li></ul></li></ul></li><li><a href="#rfc.section.10">10.</a>&nbsp;&nbsp;&nbsp;<a href="#http.headers.for.distributed.authoring">HTTP Headers for Distributed Authoring</a><ul><li><a href="#rfc.section.10.1">10.1</a>&nbsp;&nbsp;&nbsp;<a href="#HEADER_DAV">DAV Header</a></li><li><a href="#rfc.section.10.2">10.2</a>&nbsp;&nbsp;&nbsp;<a href="#HEADER_Depth">Depth Header</a></li><li><a href="#rfc.section.10.3">10.3</a>&nbsp;&nbsp;&nbsp;<a href="#HEADER_Destination">Destination Header</a></li><li><a href="#rfc.section.10.4">10.4</a>&nbsp;&nbsp;&nbsp;<a href="#HEADER_If">If Header</a><ul><li><a href="#rfc.section.10.4.1">10.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#if.header.purpose">Purpose</a></li><li><a href="#rfc.section.10.4.2">10.4.2</a>&nbsp;&nbsp;&nbsp;<a href="#if.header.syntax">Syntax</a></li><li><a href="#rfc.section.10.4.3">10.4.3</a>&nbsp;&nbsp;&nbsp;<a href="#if.header.evaluation">List Evaluation</a></li><li><a href="#rfc.section.10.4.4">10.4.4</a>&nbsp;&nbsp;&nbsp;<a href="#if.header.matching.function">Matching State Tokens and ETags</a></li><li><a href="#rfc.section.10.4.5">10.4.5</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.10.4.5">If Header and Non-DAV-Aware Proxies</a></li><li><a href="#rfc.section.10.4.6">10.4.6</a>&nbsp;&nbsp;&nbsp;<a href="#if.header.evaluation.example.no-tag">Example - No-tag Production</a></li><li><a href="#rfc.section.10.4.7">10.4.7</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.10.4.7">Example - Using "Not" with No-tag Production</a></li><li><a href="#rfc.section.10.4.8">10.4.8</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.10.4.8">Example - Causing a Condition to Always Evaluate to True</a></li><li><a href="#rfc.section.10.4.9">10.4.9</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.10.4.9">Example - Tagged List If Header in COPY</a></li><li><a href="#rfc.section.10.4.10">10.4.10</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.10.4.10">Example - Matching Lock Tokens with Collection Locks</a></li><li><a href="#rfc.section.10.4.11">10.4.11</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.10.4.11">Example - Matching ETags on Unmapped URLs</a></li></ul></li><li><a href="#rfc.section.10.5">10.5</a>&nbsp;&nbsp;&nbsp;<a href="#HEADER_Lock-Token">Lock-Token Header</a></li><li><a href="#rfc.section.10.6">10.6</a>&nbsp;&nbsp;&nbsp;<a href="#HEADER_Overwrite">Overwrite Header</a></li><li><a href="#rfc.section.10.7">10.7</a>&nbsp;&nbsp;&nbsp;<a href="#HEADER_Timeout">Timeout Request Header</a></li></ul></li><li><a href="#rfc.section.11">11.</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.extensions.to.http11">Status Code Extensions to HTTP/1.1</a><ul><li><a href="#rfc.section.11.1">11.1</a>&nbsp;&nbsp;&nbsp;<a href="#STATUS_207">207 Multi-Status</a></li><li><a href="#rfc.section.11.2">11.2</a>&nbsp;&nbsp;&nbsp;<a href="#STATUS_422">422 Unprocessable Entity</a></li><li><a href="#rfc.section.11.3">11.3</a>&nbsp;&nbsp;&nbsp;<a href="#STATUS_423">423 Locked</a></li><li><a href="#rfc.section.11.4">11.4</a>&nbsp;&nbsp;&nbsp;<a href="#STATUS_424">424 Failed Dependency</a></li><li><a href="#rfc.section.11.5">11.5</a>&nbsp;&nbsp;&nbsp;<a href="#STATUS_507">507 Insufficient Storage</a></li></ul></li><li><a href="#rfc.section.12">12.</a>&nbsp;&nbsp;&nbsp;<a href="#http-status-codes">Use of HTTP Status Codes</a><ul><li><a href="#rfc.section.12.1">12.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.12.1">412 Precondition Failed</a></li><li><a href="#rfc.section.12.2">12.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.12.2">414 Request-URI Too Long</a></li></ul></li><li><a href="#rfc.section.13">13.</a>&nbsp;&nbsp;&nbsp;<a href="#multi-status.response">Multi-Status Response</a><ul><li><a href="#rfc.section.13.1">13.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.13.1">Response Headers</a></li><li><a href="#rfc.section.13.2">13.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.13.2">Handling Redirected Child Resources</a></li><li><a href="#rfc.section.13.3">13.3</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.13.3">Internal Status Codes</a></li></ul></li><li><a href="#rfc.section.14">14.</a>&nbsp;&nbsp;&nbsp;<a href="#xml.element.definitions">XML Element Definitions</a><ul><li><a href="#rfc.section.14.1">14.1</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_activelock">activelock XML Element</a></li><li><a href="#rfc.section.14.2">14.2</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_allprop">allprop XML Element</a></li><li><a href="#rfc.section.14.3">14.3</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_collection">collection XML Element</a></li><li><a href="#rfc.section.14.4">14.4</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_depth">depth XML Element</a></li><li><a href="#rfc.section.14.5">14.5</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_error">error XML Element</a></li><li><a href="#rfc.section.14.6">14.6</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_exclusive">exclusive XML Element</a></li><li><a href="#rfc.section.14.7">14.7</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_href">href XML Element</a></li><li><a href="#rfc.section.14.8">14.8</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_include">include XML Element</a></li><li><a href="#rfc.section.14.9">14.9</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_location">location XML Element</a></li><li><a href="#rfc.section.14.10">14.10</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_lockentry">lockentry XML Element</a></li><li><a href="#rfc.section.14.11">14.11</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_lockinfo">lockinfo XML Element</a></li><li><a href="#rfc.section.14.12">14.12</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_lockroot">lockroot XML Element</a></li><li><a href="#rfc.section.14.13">14.13</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_lockscope">lockscope XML Element</a></li><li><a href="#rfc.section.14.14">14.14</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_locktoken">locktoken XML Element</a></li><li><a href="#rfc.section.14.15">14.15</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_locktype">locktype XML Element</a></li><li><a href="#rfc.section.14.16">14.16</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_multistatus">multistatus XML Element</a></li><li><a href="#rfc.section.14.17">14.17</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_owner">owner XML Element</a></li><li><a href="#rfc.section.14.18">14.18</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_prop">prop XML Element</a></li><li><a href="#rfc.section.14.19">14.19</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_propertyupdate">propertyupdate XML Element</a></li><li><a href="#rfc.section.14.20">14.20</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_propfind">propfind XML Element</a></li><li><a href="#rfc.section.14.21">14.21</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_propname">propname XML Element</a></li><li><a href="#rfc.section.14.22">14.22</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_propstat">propstat XML Element</a></li><li><a href="#rfc.section.14.23">14.23</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_remove">remove XML Element</a></li><li><a href="#rfc.section.14.24">14.24</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_response">response XML Element</a></li><li><a href="#rfc.section.14.25">14.25</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_responsedescription">responsedescription XML Element</a></li><li><a href="#rfc.section.14.26">14.26</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_set">set XML Element</a></li><li><a href="#rfc.section.14.27">14.27</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_shared">shared XML Element</a></li><li><a href="#rfc.section.14.28">14.28</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_status">status XML Element</a></li><li><a href="#rfc.section.14.29">14.29</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_timeout">timeout XML Element</a></li><li><a href="#rfc.section.14.30">14.30</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_write">write XML Element</a></li></ul></li><li><a href="#rfc.section.15">15.</a>&nbsp;&nbsp;&nbsp;<a href="#dav.properties">DAV Properties</a><ul><li><a href="#rfc.section.15.1">15.1</a>&nbsp;&nbsp;&nbsp;<a href="#PROPERTY_creationdate">creationdate Property</a></li><li><a href="#rfc.section.15.2">15.2</a>&nbsp;&nbsp;&nbsp;<a href="#PROPERTY_displayname">displayname Property</a></li><li><a href="#rfc.section.15.3">15.3</a>&nbsp;&nbsp;&nbsp;<a href="#PROPERTY_getcontentlanguage">getcontentlanguage Property</a></li><li><a href="#rfc.section.15.4">15.4</a>&nbsp;&nbsp;&nbsp;<a href="#PROPERTY_getcontentlength">getcontentlength Property</a></li><li><a href="#rfc.section.15.5">15.5</a>&nbsp;&nbsp;&nbsp;<a href="#PROPERTY_getcontenttype">getcontenttype Property</a></li><li><a href="#rfc.section.15.6">15.6</a>&nbsp;&nbsp;&nbsp;<a href="#PROPERTY_getetag">getetag Property</a></li><li><a href="#rfc.section.15.7">15.7</a>&nbsp;&nbsp;&nbsp;<a href="#PROPERTY_getlastmodified">getlastmodified Property</a></li><li><a href="#rfc.section.15.8">15.8</a>&nbsp;&nbsp;&nbsp;<a href="#PROPERTY_lockdiscovery">lockdiscovery Property</a><ul><li><a href="#rfc.section.15.8.1">15.8.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.15.8.1">Example - Retrieving DAV:lockdiscovery</a></li></ul></li><li><a href="#rfc.section.15.9">15.9</a>&nbsp;&nbsp;&nbsp;<a href="#PROPERTY_resourcetype">resourcetype Property</a></li><li><a href="#rfc.section.15.10">15.10</a>&nbsp;&nbsp;&nbsp;<a href="#PROPERTY_supportedlock">supportedlock Property</a><ul><li><a href="#rfc.section.15.10.1">15.10.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.15.10.1">Example - Retrieving DAV:supportedlock</a></li></ul></li></ul></li><li><a href="#rfc.section.16">16.</a>&nbsp;&nbsp;&nbsp;<a href="#precondition.postcondition.xml.elements">Precondition/Postcondition XML Elements</a></li><li><a href="#rfc.section.17">17.</a>&nbsp;&nbsp;&nbsp;<a href="#xml-extensibility">XML Extensibility in DAV</a></li><li><a href="#rfc.section.18">18.</a>&nbsp;&nbsp;&nbsp;<a href="#dav.compliance.classes">DAV Compliance Classes</a><ul><li><a href="#rfc.section.18.1">18.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.18.1">Class 1</a></li><li><a href="#rfc.section.18.2">18.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.18.2">Class 2</a></li><li><a href="#rfc.section.18.3">18.3</a>&nbsp;&nbsp;&nbsp;<a href="#compliance-class-3">Class 3</a></li></ul></li><li><a href="#rfc.section.19">19.</a>&nbsp;&nbsp;&nbsp;<a href="#internationalization.considerations">Internationalization Considerations</a></li><li><a href="#rfc.section.20">20.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul><li><a href="#rfc.section.20.1">20.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.20.1">Authentication of Clients</a></li><li><a href="#rfc.section.20.2">20.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.20.2">Denial of Service</a></li><li><a href="#rfc.section.20.3">20.3</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.20.3">Security through Obscurity</a></li><li><a href="#rfc.section.20.4">20.4</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.20.4">Privacy Issues Connected to Locks</a></li><li><a href="#rfc.section.20.5">20.5</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.20.5">Privacy Issues Connected to Properties</a></li><li><a href="#rfc.section.20.6">20.6</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.20.6">Implications of XML Entities</a></li><li><a href="#rfc.section.20.7">20.7</a>&nbsp;&nbsp;&nbsp;<a href="#risks.connected.with.lock.tokens">Risks Connected with Lock Tokens</a></li><li><a href="#rfc.section.20.8">20.8</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.20.8">Hosting Malicious Content</a></li></ul></li><li><a href="#rfc.section.21">21.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.21">IANA Considerations</a><ul><li><a href="#rfc.section.21.1">21.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.21.1">New URI Schemes</a></li><li><a href="#rfc.section.21.2">21.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.21.2">XML Namespaces</a></li><li><a href="#rfc.section.21.3">21.3</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.21.3">Message Header Fields</a><ul><li><a href="#rfc.section.21.3.1">21.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.21.3.1">DAV</a></li><li><a href="#rfc.section.21.3.2">21.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.21.3.2">Depth</a></li><li><a href="#rfc.section.21.3.3">21.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.21.3.3">Destination</a></li><li><a href="#rfc.section.21.3.4">21.3.4</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.21.3.4">If</a></li><li><a href="#rfc.section.21.3.5">21.3.5</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.21.3.5">Lock-Token</a></li><li><a href="#rfc.section.21.3.6">21.3.6</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.21.3.6">Overwrite</a></li><li><a href="#rfc.section.21.3.7">21.3.7</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.21.3.7">Timeout</a></li></ul></li><li><a href="#rfc.section.21.4">21.4</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.21.4">HTTP Status Codes</a></li></ul></li><li><a href="#rfc.section.22">22.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.22">Acknowledgements</a></li><li><a href="#rfc.section.23">23.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.23">Contributors to This Specification</a></li><li><a href="#rfc.section.24">24.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.24">Authors of RFC 2518</a></li><li><a href="#rfc.section.25">25.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul><li><a href="#rfc.section.25.1">25.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li><li><a href="#rfc.section.25.2">25.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li></ul></li><li><a href="#rfc.section.A">A.</a>&nbsp;&nbsp;&nbsp;<a href="#xml-appendix">Notes on Processing XML Elements</a><ul><li><a href="#rfc.section.A.1">A.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.A.1">Notes on Empty XML Elements</a></li><li><a href="#rfc.section.A.2">A.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.A.2">Notes on Illegal XML Processing</a></li><li><a href="#rfc.section.A.3">A.3</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.A.3">Example - XML Syntax Error</a></li><li><a href="#rfc.section.A.4">A.4</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.A.4">Example - Unexpected XML Element</a></li></ul></li><li><a href="#rfc.section.B">B.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.B">Notes on HTTP Client Compatibility</a></li><li><a href="#rfc.section.C">C.</a>&nbsp;&nbsp;&nbsp;<a href="#opaquelocktoken.lock.token.uri.scheme">The 'opaquelocktoken' Scheme and URIs</a></li><li><a href="#rfc.section.D">D.</a>&nbsp;&nbsp;&nbsp;<a href="#lock-null">Lock-null Resources</a><ul><li><a href="#rfc.section.D.1">D.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.D.1">Guidance for Clients Using LOCK to Create Resources</a></li></ul></li><li><a href="#rfc.section.E">E.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.E">Guidance for Clients Desiring to Authenticate</a></li><li><a href="#rfc.section.F">F.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.F">Summary of Changes from RFC 2518</a><ul><li><a href="#rfc.section.F.1">F.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.F.1">Changes for Both Client and Server Implementations</a></li><li><a href="#rfc.section.F.2">F.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.F.2">Changes for Server Implementations</a></li><li><a href="#rfc.section.F.3">F.3</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.F.3">Other Changes</a></li></ul></li><li><a href="#rfc.index">Index</a></li><li><a href="#rfc.authors">Author's Address</a></li><li><a href="#rfc.ipr">Intellectual Property and Copyright Statements</a></li></ul></nav><section id="intro"><h2 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#intro">Introduction</a></h2><div id="rfc.section.1.p.1" class="avoidbreakafter"><p>This
 document describes an extension to the HTTP/1.1 protocol that allows 
clients to perform remote Web content authoring operations. This 
extension provides a coherent set of methods, headers, request entity 
body formats, and response entity body formats that provide operations 
for:<a class="self" href="#rfc.section.1.p.1">¶</a></p></div><div id="rfc.section.1.p.2"><p>Properties: The ability to create, remove, and query information about Web pages, such as their authors, creation dates, etc.<a class="self" href="#rfc.section.1.p.2">¶</a></p></div><div id="rfc.section.1.p.3"><p>Collections:
 The ability to create sets of documents and to retrieve a hierarchical 
membership listing (like a directory listing in a file system).<a class="self" href="#rfc.section.1.p.3">¶</a></p></div><div id="rfc.section.1.p.4"><p>Locking:
 The ability to keep more than one person from working on a document at 
the same time. This prevents the "lost update problem", in which 
modifications are lost as first one author, then another, writes changes
 without merging the other author's changes.<a class="self" href="#rfc.section.1.p.4">¶</a></p></div><div id="rfc.section.1.p.5"><p>Namespace
 Operations: The ability to instruct the server to copy and move Web 
resources, operations that change the mapping from URLs to resources.<a class="self" href="#rfc.section.1.p.5">¶</a></p></div><div id="rfc.section.1.p.6"><p>Requirements
 and rationale for these operations are described in a companion 
document, "Requirements for a Distributed Authoring and Versioning 
Protocol for the World Wide Web" <a href="#RFC2291" id="rfc.xref.RFC2291.1"><cite title="Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web">[RFC2291]</cite></a>.<a class="self" href="#rfc.section.1.p.6">¶</a></p></div><div id="rfc.section.1.p.7"><p>This document does not specify the versioning operations suggested by <a href="#RFC2291" id="rfc.xref.RFC2291.2"><cite title="Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web">[RFC2291]</cite></a>. That work was done in a separate document, "Versioning Extensions to WebDAV" <a href="#RFC3253" id="rfc.xref.RFC3253.1"><cite title="Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)">[RFC3253]</cite></a>.<a class="self" href="#rfc.section.1.p.7">¶</a></p></div><div id="rfc.section.1.p.8"><p>The sections below provide a detailed introduction to various WebDAV abstractions: resource properties (<a href="#data.model.for.resource.properties" title="Data Model for Resource Properties">Section&nbsp;4</a>), collections of resources (<a href="#collections.of.web.resources" title="Collections of Web Resources">Section&nbsp;5</a>), locks (<a href="#locking" title="Locking">Section&nbsp;6</a>) in general, and write locks (<a href="#write-lock" title="Write Lock">Section&nbsp;7</a>) specifically.<a class="self" href="#rfc.section.1.p.8">¶</a></p></div><div id="rfc.section.1.p.9"><p>These abstractions are manipulated by the WebDAV-specific HTTP methods (<a href="#http.methods.for.distributed.authoring" title="HTTP Methods for Distributed Authoring">Section&nbsp;9</a>) and the extra HTTP headers (<a href="#http.headers.for.distributed.authoring" title="HTTP Headers for Distributed Authoring">Section&nbsp;10</a>) used with WebDAV methods. General considerations for handling HTTP requests and responses in WebDAV are found in <a href="#response-handling" title="General Request and Response Handling">Section&nbsp;8</a>.<a class="self" href="#rfc.section.1.p.9">¶</a></p></div><div id="rfc.section.1.p.10"><p>While
 the status codes provided by HTTP/1.1 are sufficient to describe most 
error conditions encountered by WebDAV methods, there are some errors 
that do not fall neatly into the existing categories. This specification
 defines extra status codes developed for WebDAV methods (<a href="#status.code.extensions.to.http11" title="Status Code Extensions to HTTP/1.1">Section&nbsp;11</a>) and describes existing HTTP status codes (<a href="#http-status-codes" title="Use of HTTP Status Codes">Section&nbsp;12</a>) as used in WebDAV. Since some WebDAV methods may operate over many resources, the Multi-Status response (<a href="#multi-status.response" title="Multi-Status Response">Section&nbsp;13</a>)
 has been introduced to return status information for multiple 
resources. Finally, this version of WebDAV introduces precondition and 
postcondition (<a href="#precondition.postcondition.xml.elements" title="Precondition/Postcondition XML Elements">Section&nbsp;16</a>) XML elements in error response bodies.<a class="self" href="#rfc.section.1.p.10">¶</a></p></div><div id="rfc.section.1.p.11"><p>WebDAV uses XML (<a href="#REC-XML" id="rfc.xref.REC-XML.1"><cite title="Extensible Markup Language (XML) 1.0 (Fourth Edition)">[REC-XML]</cite></a>)
 for property names and some values, and also uses XML to marshal 
complicated requests and responses. This specification contains DTD and 
text definitions of all properties (<a href="#dav.properties" title="DAV Properties">Section&nbsp;15</a>) and all other XML elements (<a href="#xml.element.definitions" title="XML Element Definitions">Section&nbsp;14</a>) used in marshalling. WebDAV includes a few special rules on extending WebDAV XML marshalling in backwards-compatible ways (<a href="#xml-extensibility" title="XML Extensibility in DAV">Section&nbsp;17</a>).<a class="self" href="#rfc.section.1.p.11">¶</a></p></div><div id="rfc.section.1.p.12"><p>Finishing off the specification are sections on what it means for a resource to be compliant with this specification (<a href="#dav.compliance.classes" title="DAV Compliance Classes">Section&nbsp;18</a>), on internationalization support (<a href="#internationalization.considerations" title="Internationalization Considerations">Section&nbsp;19</a>), and on security (<a href="#security.considerations" title="Security Considerations">Section&nbsp;20</a>).<a class="self" href="#rfc.section.1.p.12">¶</a></p></div></section><section id="n-notational-conventions"><h2 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#n-notational-conventions">Notational Conventions</a></h2><div id="rfc.section.2.p.1"><p>Since
 this document describes a set of extensions to the HTTP/1.1 protocol, 
the augmented BNF used herein to describe protocol elements is exactly 
the same as described in <a href="https://tools.ietf.org/html/rfc2616#section-2.1">Section 2.1</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, including the rules about implied linear whitespace. Since this augmented BNF uses the basic production rules provided in <a href="https://tools.ietf.org/html/rfc2616#section-2.2">Section 2.2</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, these rules apply to this document as well. Note this is not the standard BNF syntax used in other RFCs.<a class="self" href="#rfc.section.2.p.1">¶</a></p></div><div id="rfc.section.2.p.2"><p>The
 key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.<a class="self" href="#rfc.section.2.p.2">¶</a></p></div><div id="rfc.section.2.p.3"><p>Note
 that in natural language, a property like the "creationdate" property 
in the "DAV:" XML namespace is sometimes referred to as 
"DAV:creationdate" for brevity.<a class="self" href="#rfc.section.2.p.3">¶</a></p></div></section><section id="n-terminology"><h2 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a href="#n-terminology">Terminology</a></h2><div id="rfc.section.3.p.1"><p><span id="rfc.iref.u.1"></span> <span id="rfc.iref.u.2"></span> <dfn>URI</dfn>/<dfn>URL</dfn>
 - A Uniform Resource Identifier and Uniform Resource Locator, 
respectively. These terms (and the distinction between them) are defined
 in <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>.<a class="self" href="#rfc.section.3.p.1">¶</a></p></div><div id="rfc.section.3.p.2"><p><span id="rfc.iref.u.3"></span> <span id="rfc.iref.u.4"></span> <dfn>URI/URL Mapping</dfn>
 - A relation between an absolute URI and a resource. Since a resource 
can represent items that are not network retrievable, as well as those 
that are, it is possible for a resource to have zero, one, or many URI 
mappings. Mapping a resource to an "http" scheme URI makes it possible 
to submit HTTP protocol requests to the resource using the URI.<a class="self" href="#rfc.section.3.p.2">¶</a></p></div><div id="rfc.section.3.p.3"><p><span id="rfc.iref.p.1"></span> <dfn>Path Segment</dfn> - Informally, the characters found between slashes ("/") in a URI. Formally, as defined in <a href="https://tools.ietf.org/html/rfc3986#section-3.3">Section 3.3</a> of <a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>.<a class="self" href="#rfc.section.3.p.3">¶</a></p></div><div id="rfc.section.3.p.4"><p><span id="rfc.iref.c.1"></span> <dfn>Collection</dfn>
 - Informally, a resource that also acts as a container of references to
 child resources. Formally, a resource that contains a set of mappings 
between path segments and resources and meets the requirements defined 
in <a href="#collections.of.web.resources" title="Collections of Web Resources">Section&nbsp;5</a>.<a class="self" href="#rfc.section.3.p.4">¶</a></p></div><div id="rfc.section.3.p.5"><p><span id="rfc.iref.i.1"></span> <dfn>Internal Member</dfn>
 (of a Collection) - Informally, a child resource of a collection. 
Formally, a resource referenced by a path segment mapping contained in 
the collection.<a class="self" href="#rfc.section.3.p.5">¶</a></p></div><div id="rfc.section.3.p.6"><p><span id="rfc.iref.i.2"></span> <dfn>Internal Member URL</dfn>
 (of a Collection) - A URL of an internal member, consisting of the URL 
of the collection (including trailing slash) plus the path segment 
identifying the internal member.<a class="self" href="#rfc.section.3.p.6">¶</a></p></div><div id="rfc.section.3.p.7"><p><span id="rfc.iref.m.1"></span> <dfn>Member</dfn>
 (of a Collection) - Informally, a "descendant" of a collection. 
Formally, an internal member of the collection, or, recursively, a 
member of an internal member.<a class="self" href="#rfc.section.3.p.7">¶</a></p></div><div id="rfc.section.3.p.8"><p><span id="rfc.iref.m.2"></span> <dfn>Member URL</dfn>
 (of a Collection) - A URL that is either an internal member URL of the 
collection itself, or is an internal member URL of a member of that 
collection.<a class="self" href="#rfc.section.3.p.8">¶</a></p></div><div id="rfc.section.3.p.9"><p><span id="rfc.iref.p.2"></span> <dfn>Property</dfn> - A name/value pair that contains descriptive information about a resource.<a class="self" href="#rfc.section.3.p.9">¶</a></p></div><div id="rfc.section.3.p.10"><p><span id="rfc.iref.l.1"></span> <dfn>Live Property</dfn>
 - A property whose semantics and syntax are enforced by the server. For
 example, the live property DAV:getcontentlength has its value, the 
length of the entity returned by a GET request, automatically calculated
 by the server.<a class="self" href="#rfc.section.3.p.10">¶</a></p></div><div id="rfc.section.3.p.11"><p><span id="rfc.iref.d.1"></span> <dfn>Dead Property</dfn>
 - A property whose semantics and syntax are not enforced by the server.
 The server only records the value of a dead property; the client is 
responsible for maintaining the consistency of the syntax and semantics 
of a dead property.<a class="self" href="#rfc.section.3.p.11">¶</a></p></div><div id="rfc.section.3.p.12"><p><span id="rfc.iref.p.3"></span> <dfn>Principal</dfn> - A distinct human or computational actor that initiates access to network resources.<a class="self" href="#rfc.section.3.p.12">¶</a></p></div><div id="rfc.section.3.p.13"><p><span id="rfc.iref.s.1"></span> <dfn>State Token</dfn> - A URI that represents a state of a resource. Lock tokens are the only state tokens defined in this specification.<a class="self" href="#rfc.section.3.p.13">¶</a></p></div></section><section id="data.model.for.resource.properties"><h2 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a href="#data.model.for.resource.properties">Data Model for Resource Properties</a></h2><section id="n-the-resource-property-model"><h3 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a href="#n-the-resource-property-model">The Resource Property Model</a></h3><div id="rfc.section.4.1.p.1"><p>Properties are pieces of data that describe the state of a resource. Properties are data about data.<a class="self" href="#rfc.section.4.1.p.1">¶</a></p></div><div id="rfc.section.4.1.p.2"><p>Properties
 are used in distributed authoring environments to provide for efficient
 discovery and management of resources. For example, a 'subject' 
property might allow for the indexing of all resources by their subject,
 and an 'author' property might allow for the discovery of what authors 
have written which documents.<a class="self" href="#rfc.section.4.1.p.2">¶</a></p></div><div id="rfc.section.4.1.p.3"><p>The
 DAV property model consists of name/value pairs. The name of a property
 identifies the property's syntax and semantics, and provides an address
 by which to refer to its syntax and semantics.<a class="self" href="#rfc.section.4.1.p.3">¶</a></p></div><div id="rfc.section.4.1.p.4"><p>There
 are two categories of properties: "live" and "dead". A live property 
has its syntax and semantics enforced by the server. Live properties 
include cases where a) the value of a property is protected and 
maintained by the server, and b) the value of the property is maintained
 by the client, but the server performs syntax checking on submitted 
values. All instances of a given live property <em class="bcp14">MUST</em>
 comply with the definition associated with that property name. A dead 
property has its syntax and semantics enforced by the client; the server
 merely records the value of the property verbatim.<a class="self" href="#rfc.section.4.1.p.4">¶</a></p></div></section><section id="n-properties-and-http-headers"><h3 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a href="#n-properties-and-http-headers">Properties and HTTP Headers</a></h3><div id="rfc.section.4.2.p.1"><p>Properties
 already exist, in a limited sense, in HTTP message headers. However, in
 distributed authoring environments, a relatively large number of 
properties are needed to describe the state of a resource, and 
setting/returning them all through HTTP headers is inefficient. Thus, a 
mechanism is needed that allows a principal to identify a set of 
properties in which the principal is interested and to set or retrieve 
just those properties.<a class="self" href="#rfc.section.4.2.p.1">¶</a></p></div></section><section id="property_values"><h3 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a>&nbsp;<a href="#property_values">Property Values</a></h3><div id="rfc.section.4.3.p.1"><p>The value of a property is always a (well-formed) XML fragment.<a class="self" href="#rfc.section.4.3.p.1">¶</a></p></div><div id="rfc.section.4.3.p.2"><p>XML
 has been chosen because it is a flexible, self-describing, structured 
data format that supports rich schema definitions, and because of its 
support for multiple character sets. XML's self-describing nature allows
 any property's value to be extended by adding elements. Clients will 
not break when they encounter extensions because they will still have 
the data specified in the original schema and <em class="bcp14">MUST</em> ignore elements they do not understand.<a class="self" href="#rfc.section.4.3.p.2">¶</a></p></div><div id="rfc.section.4.3.p.3"><p>XML's
 support for multiple character sets allows any human-readable property 
to be encoded and read in a character set familiar to the user. XML's 
support for multiple human languages, using the "xml:lang" attribute, 
handles cases where the same character set is employed by multiple human
 languages. Note that xml:lang scope is recursive, so an xml:lang 
attribute on any element containing a property name element applies to 
the property value unless it has been overridden by a more locally 
scoped attribute. Note that a property only has one value, in one 
language (or language <em class="bcp14">MAY</em> be left undefined); a property does not have multiple values in different languages or a single value in multiple languages.<a class="self" href="#rfc.section.4.3.p.3">¶</a></p></div><div id="rfc.section.4.3.p.4" class="avoidbreakafter"><p>A
 property is always represented with an XML element consisting of the 
property name, called the "property name element". The simplest example 
is an empty property, which is different from a property that does not 
exist:<a class="self" href="#rfc.section.4.3.p.4">¶</a></p></div><div id="rfc.figure.u.1"><pre class="text">   &lt;R:title xmlns:R="http://www.example.com/ns/"&gt;&lt;/R:title&gt;</pre></div><div id="rfc.section.4.3.p.5" class="avoidbreakafter"><p>The
 value of the property appears inside the property name element. The 
value may be any kind of well-formed XML content, including both 
text-only and mixed content. Servers <em class="bcp14">MUST</em> preserve the following XML Information Items (using the terminology from <a href="#REC-XML-INFOSET" id="rfc.xref.REC-XML-INFOSET.1"><cite title="XML Information Set (Second Edition)">[REC-XML-INFOSET]</cite></a>) in storage and transmission of dead properties:<a class="self" href="#rfc.section.4.3.p.5">¶</a></p></div><div id="rfc.section.4.3.p.6" class="avoidbreakafter"><p>For the property name Element Information Item itself:<a class="self" href="#rfc.section.4.3.p.6">¶</a></p></div><div id="rfc.section.4.3.p.7"><ul class="empty"><li>[namespace name]</li><li>[local name]</li><li>[attributes] named "xml:lang" or any such attribute in scope</li><li>[children] of type element or character</li></ul></div><div id="rfc.section.4.3.p.8" class="avoidbreakafter"><p>On all Element Information Items in the property value:<a class="self" href="#rfc.section.4.3.p.8">¶</a></p></div><div id="rfc.section.4.3.p.9"><ul class="empty"><li>[namespace name]</li><li>[local name]</li><li>[attributes]</li><li>[children] of type element or character</li></ul></div><div id="rfc.section.4.3.p.10" class="avoidbreakafter"><p>On Attribute Information Items in the property value:<a class="self" href="#rfc.section.4.3.p.10">¶</a></p></div><div id="rfc.section.4.3.p.11"><ul class="empty"><li>[namespace name]</li><li>[local name]</li><li>[normalized value]</li></ul></div><div id="rfc.section.4.3.p.12" class="avoidbreakafter"><p>On Character Information Items in the property value:<a class="self" href="#rfc.section.4.3.p.12">¶</a></p></div><div id="rfc.section.4.3.p.13"><ul class="empty"><li>[character code]</li></ul></div><div id="rfc.section.4.3.p.14" class="avoidbreakafter"><p>Since prefixes are used in some XML vocabularies (XPath and XML Schema, for example), servers <em class="bcp14">SHOULD</em> preserve, for any Information Item in the value:<a class="self" href="#rfc.section.4.3.p.14">¶</a></p></div><div id="rfc.section.4.3.p.15"><ul class="empty"><li>[prefix]</li></ul></div><div id="rfc.section.4.3.p.16"><p>XML Infoset attributes not listed above <em class="bcp14">MAY</em> be preserved by the server, but clients <em class="bcp14">MUST NOT</em> rely on them being preserved. The above rules would also apply by default to live properties, unless defined otherwise.<a class="self" href="#rfc.section.4.3.p.16">¶</a></p></div><div id="rfc.section.4.3.p.17"><p>Servers <em class="bcp14">MUST</em>
 ignore the XML attribute xml:space if present and never use it to 
change whitespace handling. Whitespace in property values is 
significant.<a class="self" href="#rfc.section.4.3.p.17">¶</a></p></div><section id="n-example---property-with-mixed-content"><h4 id="rfc.section.4.3.1"><a href="#rfc.section.4.3.1">4.3.1</a>&nbsp;<a href="#n-example---property-with-mixed-content">Example - Property with Mixed Content</a></h4><div id="rfc.section.4.3.1.p.1" class="avoidbreakafter"><p>Consider a dead property 'author' created by the client as follows:<a class="self" href="#rfc.section.4.3.1.p.1">¶</a></p></div><div id="rfc.figure.u.2"><pre class="text">  &lt;D:prop xml:lang="en" xmlns:D="DAV:"&gt;
    &lt;x:author xmlns:x='http://example.com/ns'&gt;
      &lt;x:name&gt;Jane Doe&lt;/x:name&gt;
      &lt;!-- Jane's contact info --&gt;
      &lt;x:uri type='email' 
             added='2005-11-26'&gt;mailto:jane.doe@example.com&lt;/x:uri&gt;
      &lt;x:uri type='web' 
             added='2005-11-27'&gt;http://www.example.com&lt;/x:uri&gt;
      &lt;x:notes xmlns:h='http://www.w3.org/1999/xhtml'&gt;
        Jane has been working way &lt;h:em&gt;too&lt;/h:em&gt; long on the  
        long-awaited revision of &lt;![CDATA[&lt;RFC2518&gt;]]&gt;.
      &lt;/x:notes&gt;
    &lt;/x:author&gt;
  &lt;/D:prop&gt; 
        </pre></div><div id="rfc.section.4.3.1.p.2" class="avoidbreakafter"><p>When this property is requested, a server might return:<a class="self" href="#rfc.section.4.3.1.p.2">¶</a></p></div><div id="rfc.figure.u.3"><pre class="text">  &lt;D:prop xmlns:D='DAV:'&gt;&lt;author 
          xml:lang='en'
          xmlns:x='http://example.com/ns' 
          xmlns='http://example.com/ns'
          xmlns:h='http://www.w3.org/1999/xhtml'&gt;
      &lt;x:name&gt;Jane Doe&lt;/x:name&gt;
      &lt;x:uri   added="2005-11-26" type="email"
        &gt;mailto:jane.doe@example.com&lt;/x:uri&gt;
      &lt;x:uri   added="2005-11-27" type="web" 
        &gt;http://www.example.com&lt;/x:uri&gt;
      &lt;x:notes&gt;
        Jane has been working way &lt;h:em&gt;too&lt;/h:em&gt; long on the  
        long-awaited revision of &amp;lt;RFC2518&amp;gt;.
      &lt;/x:notes&gt;
    &lt;/author&gt;
  &lt;/D:prop&gt;
</pre></div><div id="rfc.section.4.3.1.p.3" class="avoidbreakafter"><p>Note in this example:<a class="self" href="#rfc.section.4.3.1.p.3">¶</a></p></div><div id="rfc.section.4.3.1.p.4"><ul><li>The
 [prefix] for the property name itself was not preserved, being 
non-significant, whereas all other [prefix] values have been preserved,</li><li>attribute
 values have been rewritten with double quotes instead of single quotes 
(quoting style is not significant), and attribute order has not been 
preserved,</li><li>the xml:lang attribute has been returned on the 
property name element itself (it was in scope when the property was set,
 but the exact position in the response is not considered significant as
 long as it is in scope),</li><li>whitespace between tags has been preserved everywhere (whitespace between attributes not so),</li><li>CDATA encapsulation was replaced with character escaping (the reverse would also be legal),</li><li>the comment item was stripped (as would have been a processing instruction item).</li></ul></div><div id="rfc.section.4.3.1.p.5"><p>Implementation
 note: there are cases such as editing scenarios where clients may 
require that XML content is preserved character by character (such as 
attribute ordering or quoting style). In this case, clients should 
consider using a text-only property value by escaping all characters 
that have a special meaning in XML parsing.<a class="self" href="#rfc.section.4.3.1.p.5">¶</a></p></div></section></section><section id="n-property-names"><h3 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a>&nbsp;<a href="#n-property-names">Property Names</a></h3><div id="rfc.section.4.4.p.1"><p>A
 property name is a universally unique identifier that is associated 
with a schema that provides information about the syntax and semantics 
of the property.<a class="self" href="#rfc.section.4.4.p.1">¶</a></p></div><div id="rfc.section.4.4.p.2"><p>Because
 a property's name is universally unique, clients can depend upon 
consistent behavior for a particular property across multiple resources,
 on the same and across different servers, so long as that property is 
"live" on the resources in question, and the implementation of the live 
property is faithful to its definition.<a class="self" href="#rfc.section.4.4.p.2">¶</a></p></div><div id="rfc.section.4.4.p.3"><p>The XML namespace mechanism, which is based on URIs (<a href="#RFC3986" id="rfc.xref.RFC3986.3"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>),
 is used to name properties because it prevents namespace collisions and
 provides for varying degrees of administrative control.<a class="self" href="#rfc.section.4.4.p.3">¶</a></p></div><div id="rfc.section.4.4.p.4"><p>The
 property namespace is flat; that is, no hierarchy of properties is 
explicitly recognized. Thus, if a property A and a property A/B exist on
 a resource, there is no recognition of any relationship between the two
 properties. It is expected that a separate specification will 
eventually be produced that will address issues relating to hierarchical
 properties.<a class="self" href="#rfc.section.4.4.p.4">¶</a></p></div><div id="rfc.section.4.4.p.5"><p>Finally,
 it is not possible to define the same property twice on a single 
resource, as this would cause a collision in the resource's property 
namespace.<a class="self" href="#rfc.section.4.4.p.5">¶</a></p></div></section><section id="n-source-resources-and-output-resources"><h3 id="rfc.section.4.5"><a href="#rfc.section.4.5">4.5</a>&nbsp;<a href="#n-source-resources-and-output-resources">Source Resources and Output Resources</a></h3><div id="rfc.section.4.5.p.1"><p>Some
 HTTP resources are dynamically generated by the server. For these 
resources, there presumably exists source code somewhere governing how 
that resource is generated. The relationship of source files to output 
HTTP resources may be one to one, one to many, many to one, or many to 
many. There is no mechanism in HTTP to determine whether a resource is 
even dynamic, let alone where its source files exist or how to author 
them. Although this problem would usefully be solved, interoperable 
WebDAV implementations have been widely deployed without actually 
solving this problem, by dealing only with static resources. Thus, the 
source vs. output problem is not solved in this specification and has 
been deferred to a separate document.<a class="self" href="#rfc.section.4.5.p.1">¶</a></p></div></section></section><section id="collections.of.web.resources"><h2 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a href="#collections.of.web.resources">Collections of Web Resources</a></h2><div id="rfc.section.5.p.1"><p>This
 section provides a description of a type of Web resource, the 
collection, and discusses its interactions with the HTTP URL namespace 
and with HTTP methods. The purpose of a collection resource is to model 
collection-like objects (e.g., file system directories) within a 
server's namespace.<a class="self" href="#rfc.section.5.p.1">¶</a></p></div><div id="rfc.section.5.p.2"><p>All DAV-compliant resources <em class="bcp14">MUST</em> support the HTTP URL namespace model specified herein.<a class="self" href="#rfc.section.5.p.2">¶</a></p></div><section id="http.url.namespace.model"><h3 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a href="#http.url.namespace.model">HTTP URL Namespace Model</a></h3><div id="rfc.section.5.1.p.1"><p>The HTTP URL namespace is a hierarchical namespace where the hierarchy is delimited with the "/" character.<a class="self" href="#rfc.section.5.1.p.1">¶</a></p></div><div id="rfc.section.5.1.p.2"><p>An
 HTTP URL namespace is said to be consistent if it meets the following 
conditions: for every URL in the HTTP hierarchy there exists a 
collection that contains that URL as an internal member URL. The root, 
or top-level collection of the namespace under consideration, is exempt 
from the previous rule. The top-level collection of the namespace under 
consideration is not necessarily the collection identified by the 
absolute path '/' -- it may be identified by one or more path segments 
(e.g., /servlets/webdav/...)<a class="self" href="#rfc.section.5.1.p.2">¶</a></p></div><div id="rfc.section.5.1.p.3"><p>Neither
 HTTP/1.1 nor WebDAV requires that the entire HTTP URL namespace be 
consistent -- a WebDAV-compatible resource may not have a parent 
collection. However, certain WebDAV methods are prohibited from 
producing results that cause namespace inconsistencies.<a class="self" href="#rfc.section.5.1.p.3">¶</a></p></div><div id="rfc.section.5.1.p.4"><p>As is implicit in <a href="#RFC2616" id="rfc.xref.RFC2616.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> and <a href="#RFC3986" id="rfc.xref.RFC3986.4"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, any resource, including collection resources, <em class="bcp14">MAY</em> be identified by more than one URI. For example, a resource could be identified by multiple HTTP URLs.<a class="self" href="#rfc.section.5.1.p.4">¶</a></p></div></section><section id="collection.resources"><h3 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;<a href="#collection.resources">Collection Resources</a></h3><div id="rfc.section.5.2.p.1"><p>Collection
 resources differ from other resources in that they also act as 
containers. Some HTTP methods apply only to a collection, but some apply
 to some or all of the resources inside the container defined by the 
collection. When the scope of a method is not clear, the client can 
specify what depth to apply. Depth can be either zero levels (only the 
collection), one level (the collection and directly contained 
resources), or infinite levels (the collection and all contained 
resources recursively).<a class="self" href="#rfc.section.5.2.p.1">¶</a></p></div><div id="rfc.section.5.2.p.2"><p>A
 collection's state consists of at least a set of mappings between path 
segments and resources, and a set of properties on the collection 
itself. In this document, a resource B will be said to be contained in 
the collection resource A if there is a path segment mapping that maps 
to B and that is contained in A. A collection <em class="bcp14">MUST</em>
 contain at most one mapping for a given path segment, i.e., it is 
illegal to have the same path segment mapped to more than one resource.<a class="self" href="#rfc.section.5.2.p.2">¶</a></p></div><div id="rfc.section.5.2.p.3"><p>Properties defined on collections behave exactly as do properties on non-collection resources. A collection <em class="bcp14">MAY</em> have additional state such as entity bodies returned by GET.<a class="self" href="#rfc.section.5.2.p.3">¶</a></p></div><div id="rfc.section.5.2.p.4"><p>For
 all WebDAV-compliant resources A and B, identified by URLs "U" and "V",
 respectively, such that "V" is equal to "U/SEGMENT", A <em class="bcp14">MUST</em>
 be a collection that contains a mapping from "SEGMENT" to B. So, if 
resource B with URL "http://example.com/bar/blah" is WebDAV compliant 
and if resource A with URL "http://example.com/bar/" is WebDAV 
compliant, then resource A must be a collection and must contain exactly
 one mapping from "blah" to B.<a class="self" href="#rfc.section.5.2.p.4">¶</a></p></div><div id="rfc.section.5.2.p.5"><p>Although
 commonly a mapping consists of a single segment and a resource, in 
general, a mapping consists of a set of segments and a resource. This 
allows a server to treat a set of segments as equivalent (i.e., either 
all of the segments are mapped to the same resource, or none of the 
segments are mapped to a resource). For example, a server that performs 
case-folding on segments will treat the segments "ab", "Ab", "aB", and 
"AB" as equivalent. A client can then use any of these segments to 
identify the resource. Note that a PROPFIND result will select one of 
these equivalent segments to identify the mapping, so there will be one 
PROPFIND response element per mapping, not one per segment in the 
mapping.<a class="self" href="#rfc.section.5.2.p.5">¶</a></p></div><div id="rfc.section.5.2.p.6"><p>Collection resources <em class="bcp14">MAY</em>
 have mappings to non-WebDAV-compliant resources in the HTTP URL 
namespace hierarchy but are not required to do so. For example, if 
resource X with URL "http://example.com/bar/blah" is not WebDAV 
compliant and resource A with "URL http://example.com/bar/" identifies a
 WebDAV collection, then A may or may not have a mapping from "blah" to 
X.<a class="self" href="#rfc.section.5.2.p.6">¶</a></p></div><div id="rfc.section.5.2.p.7"><p>If
 a WebDAV-compliant resource has no WebDAV-compliant internal members in
 the HTTP URL namespace hierarchy, then the WebDAV-compliant resource is
 not required to be a collection.<a class="self" href="#rfc.section.5.2.p.7">¶</a></p></div><div id="rfc.section.5.2.p.8"><p>There is a standing convention that when a collection is referred to by its name without a trailing slash, the server <em class="bcp14">MAY</em> handle the request as if the trailing slash were present. In this case, it <em class="bcp14">SHOULD</em>
 return a Content-Location header in the response, pointing to the URL 
ending with the "/". For example, if a client invokes a method on 
http://example.com/blah (no trailing slash), the server may respond as 
if the operation were invoked on http://example.com/blah/ (trailing 
slash), and should return a Content-Location header with the value 
http://example.com/blah/. Wherever a server produces a URL referring to a
 collection, the server <em class="bcp14">SHOULD</em> include the trailing slash. In general, clients <em class="bcp14">SHOULD</em>
 use the trailing slash form of collection names. If clients do not use 
the trailing slash form the client needs to be prepared to see a 
redirect response. Clients will find the DAV:resourcetype property more 
reliable than the URL to find out if a resource is a collection.<a class="self" href="#rfc.section.5.2.p.8">¶</a></p></div><div id="rfc.section.5.2.p.9"><p>Clients <em class="bcp14">MUST</em>
 be able to support the case where WebDAV resources are contained inside
 non-WebDAV resources. For example, if an OPTIONS response from 
"http://example.com/servlet/dav/collection" indicates WebDAV support, 
the client cannot assume that "http://example.com/servlet/dav/" or its 
parent necessarily are WebDAV collections.<a class="self" href="#rfc.section.5.2.p.9">¶</a></p></div><div id="rfc.section.5.2.p.10"><p>A
 typical scenario in which mapped URLs do not appear as members of their
 parent collection is the case where a server allows links or redirects 
to non-WebDAV resources. For instance, "/col/link" might not appear as a
 member of "/col/", although the server would respond with a 302 status 
to a GET request to "/col/link"; thus, the URL "/col/link" would indeed 
be mapped. Similarly, a dynamically-generated page might have a URL 
mapping from "/col/index.html", thus this resource might respond with a 
200 OK to a GET request yet not appear as a member of "/col/".<a class="self" href="#rfc.section.5.2.p.10">¶</a></p></div><div id="rfc.section.5.2.p.11"><p>Some
 mappings to even WebDAV-compliant resources might not appear in the 
parent collection. An example for this case are servers that support 
multiple alias URLs for each WebDAV-compliant resource. A server may 
implement case-insensitive URLs, thus "/col/a" and "/col/A" identify the
 same resource, yet only either "a" or "A" is reported upon listing the 
members of "/col". In cases where a server treats a set of segments as 
equivalent, the server <em class="bcp14">MUST</em> expose only one preferred segment per mapping, consistently chosen, in PROPFIND responses.<a class="self" href="#rfc.section.5.2.p.11">¶</a></p></div></section></section><section id="locking"><h2 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a href="#locking">Locking</a></h2><div id="rfc.section.6.p.1"><p>The
 ability to lock a resource provides a mechanism for serializing access 
to that resource. Using a lock, an authoring client can provide a 
reasonable guarantee that another principal will not modify a resource 
while it is being edited. In this way, a client can prevent the "lost 
update" problem.<a class="self" href="#rfc.section.6.p.1">¶</a></p></div><div id="rfc.section.6.p.2"><p>This
 specification allows locks to vary over two client-specified 
parameters, the number of principals involved (exclusive vs. shared) and
 the type of access to be granted. This document defines locking for 
only one access type, write. However, the syntax is extensible, and 
permits the eventual specification of locking for other access types.<a class="self" href="#rfc.section.6.p.2">¶</a></p></div><section id="lock-model"><h3 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a href="#lock-model">Lock Model</a></h3><div id="rfc.section.6.1.p.1"><p>This
 section provides a concise model for how locking behaves. Later 
sections will provide more detail on some of the concepts and refer back
 to these model statements. Normative statements related to LOCK and 
UNLOCK method handling can be found in the sections on those methods, 
whereas normative statements that cover any method are gathered here.<a class="self" href="#rfc.section.6.1.p.1">¶</a></p></div><div id="rfc.section.6.1.p.2"><ol><li>A lock either directly or indirectly locks a resource.</li><li>A
 resource becomes directly locked when a LOCK request to a URL of that 
resource creates a new lock. The "lock-root" of the new lock is that 
URL. If at the time of the request, the URL is not mapped to a resource,
 a new empty resource is created and directly locked.</li><li>An exclusive lock (<a href="#exclusive-lock" title="Exclusive vs. Shared Locks">Section&nbsp;6.2</a>) conflicts with any other kind of lock on the same resource, whether either lock is direct or indirect. A server <em class="bcp14">MUST NOT</em> create conflicting locks on a resource.</li><li>For
 a collection that is locked with a depth-infinity lock L, all member 
resources are indirectly locked. Changes in membership of such a 
collection affect the set of indirectly locked resources: <ul><li>If a member resource is added to the collection, the new member resource <em class="bcp14">MUST NOT</em> already have a conflicting lock, because the new resource <em class="bcp14">MUST</em> become indirectly locked by L.</li><li>If a member resource stops being a member of the collection, then the resource <em class="bcp14">MUST</em> no longer be indirectly locked by L.</li></ul> </li><li>Each lock is identified by a single globally unique lock token (<a href="#lock-tokens" title="Lock Tokens">Section&nbsp;6.5</a>).</li><li>An UNLOCK request deletes the lock with the specified lock token. After a lock is deleted, no resource is locked by that lock.</li><li>A lock token is "submitted" in a request when it appears in an "If" header (<a href="#write-lock" title="Write Lock">Section&nbsp;7</a>, "<a href="#write-lock" title="Write Lock">Write Lock</a>", discusses when token submission is required for write locks).</li><li>If a request causes the lock-root of any lock to become an unmapped URL, then the lock <em class="bcp14">MUST</em> also be deleted by that request.</li></ol></div></section><section id="exclusive-lock"><h3 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a href="#exclusive-lock">Exclusive vs. Shared Locks</a></h3><div id="rfc.section.6.2.p.1"><p>The
 most basic form of lock is an exclusive lock. Exclusive locks avoid 
having to deal with content change conflicts, without requiring any 
coordination other than the methods described in this specification.<a class="self" href="#rfc.section.6.2.p.1">¶</a></p></div><div id="rfc.section.6.2.p.2"><p>However,
 there are times when the goal of a lock is not to exclude others from 
exercising an access right but rather to provide a mechanism for 
principals to indicate that they intend to exercise their access rights.
 Shared locks are provided for this case. A shared lock allows multiple 
principals to receive a lock. Hence any principal that has both access 
privileges and a valid lock can use the locked resource.<a class="self" href="#rfc.section.6.2.p.2">¶</a></p></div><div id="rfc.section.6.2.p.3"><p>With
 shared locks, there are two trust sets that affect a resource. The 
first trust set is created by access permissions. Principals who are 
trusted, for example, may have permission to write to the resource. 
Among those who have access permission to write to the resource, the set
 of principals who have taken out a shared lock also must trust each 
other, creating a (typically) smaller trust set within the access 
permission write set.<a class="self" href="#rfc.section.6.2.p.3">¶</a></p></div><div id="rfc.section.6.2.p.4"><p>Starting
 with every possible principal on the Internet, in most situations the 
vast majority of these principals will not have write access to a given 
resource. Of the small number who do have write access, some principals 
may decide to guarantee their edits are free from overwrite conflicts by
 using exclusive write locks. Others may decide they trust their 
collaborators will not overwrite their work (the potential set of 
collaborators being the set of principals who have write permission) and
 use a shared lock, which informs their collaborators that a principal 
may be working on the resource.<a class="self" href="#rfc.section.6.2.p.4">¶</a></p></div><div id="rfc.section.6.2.p.5"><p>The
 WebDAV extensions to HTTP do not need to provide all of the 
communications paths necessary for principals to coordinate their 
activities. When using shared locks, principals may use any out-of-band 
communication channel to coordinate their work (e.g., face-to-face 
interaction, written notes, post-it notes on the screen, telephone 
conversation, email, etc.) The intent of a shared lock is to let 
collaborators know who else may be working on a resource.<a class="self" href="#rfc.section.6.2.p.5">¶</a></p></div><div id="rfc.section.6.2.p.6"><p>Shared
 locks are included because experience from Web-distributed authoring 
systems has indicated that exclusive locks are often too rigid. An 
exclusive lock is used to enforce a particular editing process: take out
 an exclusive lock, read the resource, perform edits, write the 
resource, release the lock. This editing process has the problem that 
locks are not always properly released, for example, when a program 
crashes or when a lock creator leaves without unlocking a resource. 
While both timeouts (<a href="#lock-timeout" title="Lock Timeout">Section&nbsp;6.6</a>)
 and administrative action can be used to remove an offending lock, 
neither mechanism may be available when needed; the timeout may be long 
or the administrator may not be available.<a class="self" href="#rfc.section.6.2.p.6">¶</a></p></div><div id="rfc.section.6.2.p.7"><p>A successful request for a new shared lock <em class="bcp14">MUST</em>
 result in the generation of a unique lock associated with the 
requesting principal. Thus, if five principals have taken out shared 
write locks on the same resource, there will be five locks and five lock
 tokens, one for each principal.<a class="self" href="#rfc.section.6.2.p.7">¶</a></p></div></section><section id="n-required-support"><h3 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a>&nbsp;<a href="#n-required-support">Required Support</a></h3><div id="rfc.section.6.3.p.1"><p>A
 WebDAV-compliant resource is not required to support locking in any 
form. If the resource does support locking, it may choose to support any
 combination of exclusive and shared locks for any access types.<a class="self" href="#rfc.section.6.3.p.1">¶</a></p></div><div id="rfc.section.6.3.p.2"><p>The
 reason for this flexibility is that locking policy strikes to the very 
heart of the resource management and versioning systems employed by 
various storage repositories. These repositories require control over 
what sort of locking will be made available. For example, some 
repositories only support shared write locks, while others only provide 
support for exclusive write locks, while yet others use no locking at 
all. As each system is sufficiently different to merit exclusion of 
certain locking features, this specification leaves locking as the sole 
axis of negotiation within WebDAV.<a class="self" href="#rfc.section.6.3.p.2">¶</a></p></div></section><section id="lock-creator"><h3 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;<a href="#lock-creator">Lock Creator and Privileges</a></h3><div id="rfc.section.6.4.p.1"><p>The
 creator of a lock has special privileges to use the lock to modify the 
resource. When a locked resource is modified, a server <em class="bcp14">MUST</em> check that the authenticated principal matches the lock creator (in addition to checking for valid lock token submission).<a class="self" href="#rfc.section.6.4.p.1">¶</a></p></div><div id="rfc.section.6.4.p.2"><p>The server <em class="bcp14">MAY</em>
 allow privileged users other than the lock creator to destroy a lock 
(for example, the resource owner or an administrator). The 'unlock' 
privilege in <a href="#RFC3744" id="rfc.xref.RFC3744.1"><cite title="Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol">[RFC3744]</cite></a> was defined to provide that permission.<a class="self" href="#rfc.section.6.4.p.2">¶</a></p></div><div id="rfc.section.6.4.p.3"><p>There is no requirement for servers to accept LOCK requests from all users or from anonymous users.<a class="self" href="#rfc.section.6.4.p.3">¶</a></p></div><div id="rfc.section.6.4.p.4"><p>Note that having a lock does not confer full privilege to modify the locked resource. Write access and other privileges <em class="bcp14">MUST</em> be enforced through normal privilege or authentication mechanisms, not based on the possible obscurity of lock token values.<a class="self" href="#rfc.section.6.4.p.4">¶</a></p></div></section><section id="lock-tokens"><h3 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a>&nbsp;<a href="#lock-tokens">Lock Tokens</a></h3><div id="rfc.section.6.5.p.1"><p>A
 lock token is a type of state token that identifies a particular lock. 
Each lock has exactly one unique lock token generated by the server. 
Clients <em class="bcp14">MUST NOT</em> attempt to interpret lock tokens in any way.<a class="self" href="#rfc.section.6.5.p.1">¶</a></p></div><div id="rfc.section.6.5.p.2"><p>Lock token URIs <em class="bcp14">MUST</em>
 be unique across all resources for all time. This uniqueness constraint
 allows lock tokens to be submitted across resources and servers without
 fear of confusion. Since lock tokens are unique, a client <em class="bcp14">MAY</em> submit a lock token in an If header on a resource other than the one that returned it.<a class="self" href="#rfc.section.6.5.p.2">¶</a></p></div><div id="rfc.section.6.5.p.3"><p>When a LOCK operation creates a new lock, the new lock token is returned in the Lock-Token response header defined in <a href="#HEADER_Lock-Token" title="Lock-Token Header">Section&nbsp;10.5</a>, and also in the body of the response.<a class="self" href="#rfc.section.6.5.p.3">¶</a></p></div><div id="rfc.section.6.5.p.4"><p>Servers <em class="bcp14">MAY</em>
 make lock tokens publicly readable (e.g., in the DAV:lockdiscovery 
property). One use case for making lock tokens readable is so that a 
long-lived lock can be removed by the resource owner (the client that 
obtained the lock might have crashed or disconnected before cleaning up 
the lock). Except for the case of using UNLOCK under user guidance, a 
client <em class="bcp14">SHOULD NOT</em> use a lock token created by another client instance.<a class="self" href="#rfc.section.6.5.p.4">¶</a></p></div><div id="rfc.section.6.5.p.5"><p>This
 specification encourages servers to create Universally Unique 
Identifiers (UUIDs) for lock tokens, and to use the URI form defined by 
"A Universally Unique Identifier (UUID) URN Namespace" (<a href="#RFC4122" id="rfc.xref.RFC4122.1"><cite title="A Universally Unique IDentifier (UUID) URN Namespace">[RFC4122]</cite></a>).
 However, servers are free to use any URI (e.g., from another scheme) so
 long as it meets the uniqueness requirements. For example, a valid lock
 token might be constructed using the "opaquelocktoken" scheme defined 
in <a href="#opaquelocktoken.lock.token.uri.scheme" title="The 'opaquelocktoken' Scheme and URIs">Appendix&nbsp;C</a>.<a class="self" href="#rfc.section.6.5.p.5">¶</a></p></div><div id="rfc.section.6.5.p.6"><p>Example: "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"<a class="self" href="#rfc.section.6.5.p.6">¶</a></p></div></section><section id="lock-timeout"><h3 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a>&nbsp;<a href="#lock-timeout">Lock Timeout</a></h3><div id="rfc.section.6.6.p.1"><p>A lock <em class="bcp14">MAY</em>
 have a limited lifetime. The lifetime is suggested by the client when 
creating or refreshing the lock, but the server ultimately chooses the 
timeout value. Timeout is measured in seconds remaining until lock 
expiration.<a class="self" href="#rfc.section.6.6.p.1">¶</a></p></div><div id="rfc.section.6.6.p.2"><p>The timeout counter <em class="bcp14">MUST</em> be restarted if a refresh lock request is successful (see <a href="#refreshing-locks" title="Refreshing Locks">Section&nbsp;9.10.2</a>). The timeout counter <em class="bcp14">SHOULD NOT</em> be restarted at any other time.<a class="self" href="#rfc.section.6.6.p.2">¶</a></p></div><div id="rfc.section.6.6.p.3"><p>If the timeout expires, then the lock <em class="bcp14">SHOULD</em> be removed. In this case the server <em class="bcp14">SHOULD</em>
 act as if an UNLOCK method was executed by the server on the resource 
using the lock token of the timed-out lock, performed with its override 
authority.<a class="self" href="#rfc.section.6.6.p.3">¶</a></p></div><div id="rfc.section.6.6.p.4"><p>Servers
 are advised to pay close attention to the values submitted by clients, 
as they will be indicative of the type of activity the client intends to
 perform. For example, an applet running in a browser may need to lock a
 resource, but because of the instability of the environment within 
which the applet is running, the applet may be turned off without 
warning. As a result, the applet is likely to ask for a relatively small
 timeout value so that if the applet dies, the lock can be quickly 
harvested. However, a document management system is likely to ask for an
 extremely long timeout because its user may be planning on going 
offline.<a class="self" href="#rfc.section.6.6.p.4">¶</a></p></div><div id="rfc.section.6.6.p.5"><p>A client <em class="bcp14">MUST NOT</em> assume that just because the timeout has expired, the lock has immediately been removed.<a class="self" href="#rfc.section.6.6.p.5">¶</a></p></div><div id="rfc.section.6.6.p.6"><p>Likewise, a client <em class="bcp14">MUST NOT</em> assume that just because the timeout has not expired, the lock still exists. Clients <em class="bcp14">MUST</em>
 assume that locks can arbitrarily disappear at any time, regardless of 
the value given in the Timeout header. The Timeout header only indicates
 the behavior of the server if extraordinary circumstances do not occur.
 For example, a sufficiently privileged user may remove a lock at any 
time, or the system may crash in such a way that it loses the record of 
the lock's existence.<a class="self" href="#rfc.section.6.6.p.6">¶</a></p></div></section><section id="n-lock-capability-discovery"><h3 id="rfc.section.6.7"><a href="#rfc.section.6.7">6.7</a>&nbsp;<a href="#n-lock-capability-discovery">Lock Capability Discovery</a></h3><div id="rfc.section.6.7.p.1"><p>Since
 server lock support is optional, a client trying to lock a resource on a
 server can either try the lock and hope for the best, or perform some 
form of discovery to determine what lock capabilities the server 
supports. This is known as lock capability discovery. A client can 
determine what lock types the server supports by retrieving the 
DAV:supportedlock property.<a class="self" href="#rfc.section.6.7.p.1">¶</a></p></div><div id="rfc.section.6.7.p.2"><p>Any DAV-compliant resource that supports the LOCK method <em class="bcp14">MUST</em> support the DAV:supportedlock property.<a class="self" href="#rfc.section.6.7.p.2">¶</a></p></div></section><section id="n-active-lock-discovery"><h3 id="rfc.section.6.8"><a href="#rfc.section.6.8">6.8</a>&nbsp;<a href="#n-active-lock-discovery">Active Lock Discovery</a></h3><div id="rfc.section.6.8.p.1"><p>If
 another principal locks a resource that a principal wishes to access, 
it is useful for the second principal to be able to find out who the 
first principal is. For this purpose the DAV:lockdiscovery property is 
provided. This property lists all outstanding locks, describes their 
type, and <em class="bcp14">MAY</em> even provide the lock tokens.<a class="self" href="#rfc.section.6.8.p.1">¶</a></p></div><div id="rfc.section.6.8.p.2"><p>Any DAV-compliant resource that supports the LOCK method <em class="bcp14">MUST</em> support the DAV:lockdiscovery property.<a class="self" href="#rfc.section.6.8.p.2">¶</a></p></div></section></section><section id="write-lock"><h2 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a href="#write-lock">Write Lock</a></h2><div id="rfc.section.7.p.1"><p>This
 section describes the semantics specific to the write lock type. The 
write lock is a specific instance of a lock type, and is the only lock 
type described in this specification.<a class="self" href="#rfc.section.7.p.1">¶</a></p></div><div id="rfc.section.7.p.2"><p>An
 exclusive write lock protects a resource: it prevents changes by any 
principal other than the lock creator and in any case where the lock 
token is not submitted (e.g., by a client process other than the one 
holding the lock).<a class="self" href="#rfc.section.7.p.2">¶</a></p></div><div id="rfc.section.7.p.3" class="avoidbreakafter"><p>Clients <em class="bcp14">MUST</em>
 submit a lock-token they are authorized to use in any request that 
modifies a write-locked resource. The list of modifications covered by a
 write-lock include:<a class="self" href="#rfc.section.7.p.3">¶</a></p></div><div id="rfc.section.7.p.4"><ol><li>A change to any of the following aspects of any write-locked resource: <ul><li>any variant,</li><li>any dead property,</li><li>any live property that is lockable (a live property is lockable unless otherwise defined.)</li></ul> </li><li>For
 collections, any modification of an internal member URI. An internal 
member URI of a collection is considered to be modified if it is added, 
removed, or identifies a different resource. More discussion on write 
locks and collections is found in <a href="#write.locks.and.collections" title="Write Locks and Collections">Section&nbsp;7.4</a>.</li><li>A modification of the mapping of the root of the write lock, either to another resource or to no resource (e.g., DELETE).</li></ol></div><div id="rfc.section.7.p.5"><p>Of
 the methods defined in HTTP and WebDAV, PUT, POST, PROPPATCH, LOCK, 
UNLOCK, MOVE, COPY (for the destination resource), DELETE, and MKCOL are
 affected by write locks. All other HTTP/WebDAV methods defined so far 
-- GET in particular -- function independently of a write lock.<a class="self" href="#rfc.section.7.p.5">¶</a></p></div><div id="rfc.section.7.p.6"><p>The next few sections describe in more specific terms how write locks interact with various operations.<a class="self" href="#rfc.section.7.p.6">¶</a></p></div><section id="n-write-locks-and-properties"><h3 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a href="#n-write-locks-and-properties">Write Locks and Properties</a></h3><div id="rfc.section.7.1.p.1"><p>While
 those without a write lock may not alter a property on a resource it is
 still possible for the values of live properties to change, even while 
locked, due to the requirements of their schemas. Only dead properties 
and live properties defined as lockable are guaranteed not to change 
while write locked.<a class="self" href="#rfc.section.7.1.p.1">¶</a></p></div></section><section id="n-avoiding-lost-updates"><h3 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;<a href="#n-avoiding-lost-updates">Avoiding Lost Updates</a></h3><div id="rfc.section.7.2.p.1" class="avoidbreakafter"><p>Although
 the write locks provide some help in preventing lost updates, they 
cannot guarantee that updates will never be lost. Consider the following
 scenario:<a class="self" href="#rfc.section.7.2.p.1">¶</a></p></div><div id="rfc.section.7.2.p.2"><p>Two
 clients A and B are interested in editing the resource 'index.html'. 
Client A is an HTTP client rather than a WebDAV client, and so does not 
know how to perform locking.<a class="self" href="#rfc.section.7.2.p.2">¶</a></p></div><div id="rfc.section.7.2.p.3"><p>Client A doesn't lock the document, but does a GET, and begins editing.<a class="self" href="#rfc.section.7.2.p.3">¶</a></p></div><div id="rfc.section.7.2.p.4"><p>Client B does LOCK, performs a GET and begins editing.<a class="self" href="#rfc.section.7.2.p.4">¶</a></p></div><div id="rfc.section.7.2.p.5"><p>Client B finishes editing, performs a PUT, then an UNLOCK.<a class="self" href="#rfc.section.7.2.p.5">¶</a></p></div><div id="rfc.section.7.2.p.6"><p>Client A performs a PUT, overwriting and losing all of B's changes.<a class="self" href="#rfc.section.7.2.p.6">¶</a></p></div><div id="rfc.section.7.2.p.7"><p>There
 are several reasons why the WebDAV protocol itself cannot prevent this 
situation. First, it cannot force all clients to use locking because it 
must be compatible with HTTP clients that do not comprehend locking. 
Second, it cannot require servers to support locking because of the 
variety of repository implementations, some of which rely on 
reservations and merging rather than on locking. Finally, being 
stateless, it cannot enforce a sequence of operations like LOCK / GET / 
PUT / UNLOCK.<a class="self" href="#rfc.section.7.2.p.7">¶</a></p></div><div id="rfc.section.7.2.p.8"><p>WebDAV
 servers that support locking can reduce the likelihood that clients 
will accidentally overwrite each other's changes by requiring clients to
 lock resources before modifying them. Such servers would effectively 
prevent HTTP 1.0 and HTTP 1.1 clients from modifying resources.<a class="self" href="#rfc.section.7.2.p.8">¶</a></p></div><div id="rfc.section.7.2.p.9"><p>WebDAV
 clients can be good citizens by using a lock / retrieve / write /unlock
 sequence of operations (at least by default) whenever they interact 
with a WebDAV server that supports locking.<a class="self" href="#rfc.section.7.2.p.9">¶</a></p></div><div id="rfc.section.7.2.p.10"><p>HTTP
 1.1 clients can be good citizens, avoiding overwriting other clients' 
changes, by using entity tags in If-Match headers with any requests that
 would modify resources.<a class="self" href="#rfc.section.7.2.p.10">¶</a></p></div><div id="rfc.section.7.2.p.11"><p>Information
 managers may attempt to prevent overwrites by implementing client-side 
procedures requiring locking before modifying WebDAV resources.<a class="self" href="#rfc.section.7.2.p.11">¶</a></p></div></section><section id="lock-unmapped-urls"><h3 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a>&nbsp;<a href="#lock-unmapped-urls">Write Locks and Unmapped URLs</a></h3><div id="rfc.section.7.3.p.1"><p>WebDAV
 provides the ability to send a LOCK request to an unmapped URL in order
 to reserve the name for use. This is a simple way to avoid the 
lost-update problem on the creation of a new resource (another way is to
 use If-None-Match header specified in <a href="https://tools.ietf.org/html/rfc2616#section-14.26">Section 14.26</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>). It has the side benefit of locking the new resource immediately for use of the creator.<a class="self" href="#rfc.section.7.3.p.1">¶</a></p></div><div id="rfc.section.7.3.p.2"><p>Note
 that the lost-update problem is not an issue for collections because 
MKCOL can only be used to create a collection, not to overwrite an 
existing collection. When trying to lock a collection upon creation, 
clients can attempt to increase the likelihood of getting the lock by 
pipelining the MKCOL and LOCK requests together (but because this 
doesn't convert two separate operations into one atomic operation, 
there's no guarantee this will work).<a class="self" href="#rfc.section.7.3.p.2">¶</a></p></div><div id="rfc.section.7.3.p.3"><p>A successful lock request to an unmapped URL <em class="bcp14">MUST</em>
 result in the creation of a locked (non-collection) resource with empty
 content. Subsequently, a successful PUT request (with the correct lock 
token) provides the content for the resource. Note that the LOCK request
 has no mechanism for the client to provide Content-Type or 
Content-Language, thus the server will use defaults or empty values and 
rely on the subsequent PUT request for correct values.<a class="self" href="#rfc.section.7.3.p.3">¶</a></p></div><div id="rfc.section.7.3.p.4" class="avoidbreakafter"><p>A
 resource created with a LOCK is empty but otherwise behaves in every 
way as a normal resource. It behaves the same way as a resource created 
by a PUT request with an empty body (and where a Content-Type and 
Content-Language was not specified), followed by a LOCK request to the 
same resource. Following from this model, a locked empty resource:<a class="self" href="#rfc.section.7.3.p.4">¶</a></p></div><div id="rfc.section.7.3.p.5"><ul><li>Can be read, deleted, moved, and copied, and in all ways behaves as a regular non-collection resource.</li><li>Appears as a member of its parent collection.</li><li><em class="bcp14">SHOULD NOT</em>
 disappear when its lock goes away (clients must therefore be 
responsible for cleaning up their own mess, as with any other operation 
or any non-empty resource).</li><li><em class="bcp14">MAY</em> NOT have values for properties like DAV:getcontentlanguage that haven't been specified yet by the client.</li><li>Can be updated (have content added) with a PUT request.</li><li><em class="bcp14">MUST NOT</em> be converted into a collection. The server <em class="bcp14">MUST</em> fail a MKCOL request (as it would with a MKCOL request to any existing non-collection resource).</li><li><em class="bcp14">MUST</em> have defined values for DAV:lockdiscovery and DAV:supportedlock properties.</li><li>The response <em class="bcp14">MUST</em>
 indicate that a resource was created, by use of the "201 Created" 
response code (a LOCK request to an existing resource instead will 
result in 200 OK). The body must still include the DAV:lockdiscovery 
property, as with a LOCK request to an existing resource.</li></ul></div><div id="rfc.section.7.3.p.6"><p>The client is expected to update the locked empty resource shortly after locking it, using PUT and possibly PROPPATCH.<a class="self" href="#rfc.section.7.3.p.6">¶</a></p></div><div id="rfc.section.7.3.p.7"><p>Alternatively and for backwards compatibility to <a href="#RFC2518" id="rfc.xref.RFC2518.1"><cite title="HTTP Extensions for Distributed Authoring -- WEBDAV">[RFC2518]</cite></a>, servers <em class="bcp14">MAY</em> implement Lock-Null Resources (LNRs) instead (see definition in <a href="#lock-null" title="Lock-null Resources">Appendix&nbsp;D</a>).
 Clients can easily interoperate both with servers that support the old 
model LNRs and the recommended model of "locked empty resources" by only
 attempting PUT after a LOCK to an unmapped URL, not MKCOL or GET, and 
by not relying on specific properties of LNRs.<a class="self" href="#rfc.section.7.3.p.7">¶</a></p></div></section><section id="write.locks.and.collections"><h3 id="rfc.section.7.4"><a href="#rfc.section.7.4">7.4</a>&nbsp;<a href="#write.locks.and.collections">Write Locks and Collections</a></h3><div id="rfc.section.7.4.p.1"><p>There
 are two kinds of collection write locks. A depth-0 write lock on a 
collection protects the collection properties plus the internal member 
URLs of that one collection, while not protecting the content or 
properties of member resources (if the collection itself has any entity 
bodies, those are also protected). A depth-infinity write lock on a 
collection provides the same protection on that collection and also 
provides write lock protection on every member resource.<a class="self" href="#rfc.section.7.4.p.1">¶</a></p></div><div id="rfc.section.7.4.p.2"><p>Expressed
 otherwise, a write lock of either kind protects any request that would 
create a new resource in a write locked collection, any request that 
would remove an internal member URL of a write locked collection, and 
any request that would change the segment name of any internal member.<a class="self" href="#rfc.section.7.4.p.2">¶</a></p></div><div id="rfc.section.7.4.p.3" class="avoidbreakafter"><p>Thus, a collection write lock protects all the following actions:<a class="self" href="#rfc.section.7.4.p.3">¶</a></p></div><div id="rfc.section.7.4.p.4"><ul><li>DELETE a collection's direct internal member,</li><li>MOVE an internal member out of the collection,</li><li>MOVE an internal member into the collection,</li><li>MOVE to rename an internal member within a collection,</li><li>COPY an internal member into a collection, and</li><li>PUT or MKCOL request that would create a new internal member.</li></ul></div><div id="rfc.section.7.4.p.5"><p>The collection's lock token is required in addition to the lock token on the internal member itself, if it is locked separately.<a class="self" href="#rfc.section.7.4.p.5">¶</a></p></div><div id="rfc.section.7.4.p.6"><p>In
 addition, a depth-infinity lock affects all write operations to all 
members of the locked collection. With a depth-infinity lock, the 
resource identified by the root of the lock is directly locked, and all 
its members are indirectly locked.<a class="self" href="#rfc.section.7.4.p.6">¶</a></p></div><div id="rfc.section.7.4.p.7"><ul><li>Any new resource added as a descendant of a depth-infinity locked collection becomes indirectly locked.</li><li>Any indirectly locked resource moved out of the locked collection into an unlocked collection is thereafter unlocked.</li><li>Any
 indirectly locked resource moved out of a locked source collection into
 a depth-infinity locked target collection remains indirectly locked but
 is now protected by the lock on the target collection (the target 
collection's lock token will thereafter be required to make further 
changes).</li></ul></div><div id="rfc.section.7.4.p.8"><p>If a 
depth-infinity write LOCK request is issued to a collection containing 
member URLs identifying resources that are currently locked in a manner 
that conflicts with the new lock (see <a href="#lock-model" title="Lock Model">Section&nbsp;6.1</a>, point 3), the request <em class="bcp14">MUST</em> fail with a 423 (Locked) status code, and the response <em class="bcp14">SHOULD</em> contain the 'no-conflicting-lock' precondition.<a class="self" href="#rfc.section.7.4.p.8">¶</a></p></div><div id="rfc.section.7.4.p.9"><p>If
 a lock request causes the URL of a resource to be added as an internal 
member URL of a depth-infinity locked collection, then the new resource <em class="bcp14">MUST</em>
 be automatically protected by the lock. For example, if the collection 
/a/b/ is write locked and the resource /c is moved to /a/b/c, then 
resource /a/b/c will be added to the write lock.<a class="self" href="#rfc.section.7.4.p.9">¶</a></p></div></section><section id="write.locks.and.the.if.request.header"><h3 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a>&nbsp;<a href="#write.locks.and.the.if.request.header">Write Locks and the If Request Header</a></h3><div id="rfc.section.7.5.p.1"><p>A
 user agent has to demonstrate knowledge of a lock when requesting an 
operation on a locked resource. Otherwise, the following scenario might 
occur. In the scenario, program A, run by User A, takes out a write lock
 on a resource. Program B, also run by User A, has no knowledge of the 
lock taken out by program A, yet performs a PUT to the locked resource. 
In this scenario, the PUT succeeds because locks are associated with a 
principal, not a program, and thus program B, because it is acting with 
principal A's credential, is allowed to perform the PUT. However, had 
program B known about the lock, it would not have overwritten the 
resource, preferring instead to present a dialog box describing the 
conflict to the user. Due to this scenario, a mechanism is needed to 
prevent different programs from accidentally ignoring locks taken out by
 other programs with the same authorization.<a class="self" href="#rfc.section.7.5.p.1">¶</a></p></div><div id="rfc.section.7.5.p.2"><p>In order to prevent these collisions, a lock token <em class="bcp14">MUST</em> be submitted by an authorized principal for all locked resources that a method may change or the method <em class="bcp14">MUST</em>
 fail. A lock token is submitted when it appears in an If header. For 
example, if a resource is to be moved and both the source and 
destination are locked, then two lock tokens must be submitted in the If
 header, one for the source and the other for the destination.<a class="self" href="#rfc.section.7.5.p.2">¶</a></p></div><section id="n-example---write-lock-and-copy"><h4 id="rfc.section.7.5.1"><a href="#rfc.section.7.5.1">7.5.1</a>&nbsp;<a href="#n-example---write-lock-and-copy">Example - Write Lock and COPY</a></h4><div id="rfc.figure.u.4"><p>&gt;&gt;Request</p><pre class="text2">  COPY /~fielding/index.html HTTP/1.1 
  Host: www.example.com 
  Destination: http://www.example.com/users/f/fielding/index.html 
  If: &lt;http://www.example.com/users/f/fielding/index.html&gt; 
      (&lt;urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6&gt;) 
</pre></div><div id="rfc.figure.u.5"><p>&gt;&gt;Response</p><pre class="text">  HTTP/1.1 204 No Content 
</pre></div><div id="rfc.section.7.5.1.p.1"><p>In this example, even 
though both the source and destination are locked, only one lock token 
must be submitted (the one for the lock on the destination). This is 
because the source resource is not modified by a COPY, and hence 
unaffected by the write lock. In this example, user agent authentication
 has previously occurred via a mechanism outside the scope of the HTTP 
protocol, in the underlying transport layer.<a class="self" href="#rfc.section.7.5.1.p.1">¶</a></p></div></section><section id="n-example---deleting-a-member-of-a-locked-collection"><h4 id="rfc.section.7.5.2"><a href="#rfc.section.7.5.2">7.5.2</a>&nbsp;<a href="#n-example---deleting-a-member-of-a-locked-collection">Example - Deleting a Member of a Locked Collection</a></h4><div id="rfc.section.7.5.2.p.1" class="avoidbreakafter"><p>Consider
 a collection "/locked" with an exclusive, depth-infinity write lock, 
and an attempt to delete an internal member "/locked/member":<a class="self" href="#rfc.section.7.5.2.p.1">¶</a></p></div><div id="rfc.figure.u.6"><p>&gt;&gt;Request</p><pre class="text2">  DELETE /locked/member HTTP/1.1
  Host: example.com          
</pre></div><div id="rfc.figure.u.7"><p>&gt;&gt;Response</p><pre class="text">  HTTP/1.1 423 Locked
  Content-Type: application/xml; charset="utf-8"
  Content-Length: xxxx

  &lt;?xml version="1.0" encoding="utf-8" ?&gt;
  &lt;D:error xmlns:D="DAV:"&gt;
    &lt;D:lock-token-submitted&gt;
      &lt;D:href&gt;/locked/&lt;/D:href&gt;
    &lt;/D:lock-token-submitted&gt;
  &lt;/D:error&gt;
</pre></div><div id="rfc.section.7.5.2.p.2"><p>Thus, the client would 
need to submit the lock token with the request to make it succeed. To do
 that, various forms of the If header (see <a href="#HEADER_If" title="If Header">Section&nbsp;10.4</a>) could be used.<a class="self" href="#rfc.section.7.5.2.p.2">¶</a></p></div><div id="rfc.section.7.5.2.p.3" class="avoidbreakafter"><p>"No-Tag-List" format:<a class="self" href="#rfc.section.7.5.2.p.3">¶</a></p></div><div id="rfc.figure.u.8"><pre class="text">  If: (&lt;urn:uuid:150852e2-3847-42d5-8cbe-0f4f296f26cf&gt;)
</pre></div><div id="rfc.section.7.5.2.p.4" class="avoidbreakafter"><p>"Tagged-List" format, for "http://example.com/locked/":<a class="self" href="#rfc.section.7.5.2.p.4">¶</a></p></div><div id="rfc.figure.u.9"><pre class="text">  If: &lt;http://example.com/locked/&gt;
      (&lt;urn:uuid:150852e2-3847-42d5-8cbe-0f4f296f26cf&gt;)      
</pre></div><div id="rfc.section.7.5.2.p.5" class="avoidbreakafter"><p>"Tagged-List" format, for "http://example.com/locked/member":<a class="self" href="#rfc.section.7.5.2.p.5">¶</a></p></div><div id="rfc.figure.u.10"><pre class="text">  If: &lt;http://example.com/locked/member&gt;
      (&lt;urn:uuid:150852e2-3847-42d5-8cbe-0f4f296f26cf&gt;)
</pre></div><div id="rfc.section.7.5.2.p.6"><p>Note that, for the 
purpose of submitting the lock token, the actual form doesn't matter; 
what's relevant is that the lock token appears in the If header, and 
that the If header itself evaluates to true.<a class="self" href="#rfc.section.7.5.2.p.6">¶</a></p></div></section></section><section id="n-write-locks-and-copy-move"><h3 id="rfc.section.7.6"><a href="#rfc.section.7.6">7.6</a>&nbsp;<a href="#n-write-locks-and-copy-move">Write Locks and COPY/MOVE</a></h3><div id="rfc.section.7.6.p.1"><p>A COPY method invocation <em class="bcp14">MUST NOT</em>
 duplicate any write locks active on the source. However, as previously 
noted, if the COPY copies the resource into a collection that is locked 
with a depth-infinity lock, then the resource will be added to the lock.<a class="self" href="#rfc.section.7.6.p.1">¶</a></p></div><div id="rfc.section.7.6.p.2"><p>A successful MOVE request on a write locked resource <em class="bcp14">MUST NOT</em> move the write lock with the resource. However, if there is an existing lock at the destination, the server <em class="bcp14">MUST</em>
 add the moved resource to the destination lock scope. For example, if 
the MOVE makes the resource a child of a collection that has a 
depth-infinity lock, then the resource will be added to that 
collection's lock. Additionally, if a resource with a depth-infinity 
lock is moved to a destination that is within the scope of the same lock
 (e.g., within the URL namespace tree covered by the lock), the moved 
resource will again be added to the lock. In both these examples, as 
specified in <a href="#write.locks.and.the.if.request.header" title="Write Locks and the If Request Header">Section&nbsp;7.5</a>, an If header must be submitted containing a lock token for both the source and destination.<a class="self" href="#rfc.section.7.6.p.2">¶</a></p></div></section><section id="n-refreshing-write-locks"><h3 id="rfc.section.7.7"><a href="#rfc.section.7.7">7.7</a>&nbsp;<a href="#n-refreshing-write-locks">Refreshing Write Locks</a></h3><div id="rfc.section.7.7.p.1"><p>A client <em class="bcp14">MUST NOT</em>
 submit the same write lock request twice. Note that a client is always 
aware it is resubmitting the same lock request because it must include 
the lock token in the If header in order to make the request for a 
resource that is already locked.<a class="self" href="#rfc.section.7.7.p.1">¶</a></p></div><div id="rfc.section.7.7.p.2"><p>However,
 a client may submit a LOCK request with an If header but without a 
body. A server receiving a LOCK request with no body <em class="bcp14">MUST NOT</em>
 create a new lock -- this form of the LOCK request is only to be used 
to "refresh" an existing lock (meaning, at minimum, that any timers 
associated with the lock <em class="bcp14">MUST</em> be reset).<a class="self" href="#rfc.section.7.7.p.2">¶</a></p></div><div id="rfc.section.7.7.p.3"><p>Clients
 may submit Timeout headers of arbitrary value with their lock refresh 
requests. Servers, as always, may ignore Timeout headers submitted by 
the client, and a server <em class="bcp14">MAY</em> refresh a lock with a
 timeout period that is different than the previous timeout period used 
for the lock, provided it advertises the new value in the LOCK refresh 
response.<a class="self" href="#rfc.section.7.7.p.3">¶</a></p></div><div id="rfc.section.7.7.p.4"><p>If an error is received in response to a refresh LOCK request, the client <em class="bcp14">MUST NOT</em> assume that the lock was refreshed.<a class="self" href="#rfc.section.7.7.p.4">¶</a></p></div></section></section><section id="response-handling"><h2 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a href="#response-handling">General Request and Response Handling</a></h2><section id="error-precedence"><h3 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a href="#error-precedence">Precedence in Error Handling</a></h3><div id="rfc.section.8.1.p.1"><p>Servers <em class="bcp14">MUST</em>
 return authorization errors in preference to other errors. This avoids 
leaking information about protected resources (e.g., a client that finds
 that a hidden resource exists by seeing a 423 Locked response to an 
anonymous request to the resource).<a class="self" href="#rfc.section.8.1.p.1">¶</a></p></div></section><section id="n-use-of-xml"><h3 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a>&nbsp;<a href="#n-use-of-xml">Use of XML</a></h3><div id="rfc.section.8.2.p.1"><p>In
 HTTP/1.1, method parameter information was exclusively encoded in HTTP 
headers. Unlike HTTP/1.1, WebDAV encodes method parameter information 
either in an XML (<a href="#REC-XML" id="rfc.xref.REC-XML.2"><cite title="Extensible Markup Language (XML) 1.0 (Fourth Edition)">[REC-XML]</cite></a>)
 request entity body, or in an HTTP header. The use of XML to encode 
method parameters was motivated by the ability to add extra XML elements
 to existing structures, providing extensibility; and by XML's ability 
to encode information in ISO 10646 character sets, providing 
internationalization support.<a class="self" href="#rfc.section.8.2.p.1">¶</a></p></div><div id="rfc.section.8.2.p.2"><p>In
 addition to encoding method parameters, XML is used in WebDAV to encode
 the responses from methods, providing the extensibility and 
internationalization advantages of XML for method output, as well as 
input.<a class="self" href="#rfc.section.8.2.p.2">¶</a></p></div><div id="rfc.section.8.2.p.3"><p>When XML is used for a request or response body, the Content-Type type <em class="bcp14">SHOULD</em> be application/xml. Implementations <em class="bcp14">MUST</em> accept both text/xml and application/xml in request and response bodies. Use of text/xml is deprecated.<a class="self" href="#rfc.section.8.2.p.3">¶</a></p></div><div id="rfc.section.8.2.p.4"><p>All DAV-compliant clients and resources <em class="bcp14">MUST</em> use XML parsers that are compliant with <a href="#REC-XML" id="rfc.xref.REC-XML.3"><cite title="Extensible Markup Language (XML) 1.0 (Fourth Edition)">[REC-XML]</cite></a> and <a href="#REC-XML-NAMES" id="rfc.xref.REC-XML-NAMES.1"><cite title="Namespaces in XML 1.0 (Second Edition)">[REC-XML-NAMES]</cite></a>. All XML used in either requests or responses <em class="bcp14">MUST</em> be, at minimum, well formed and use namespaces correctly. If a server receives XML that is not well-formed, then the server <em class="bcp14">MUST</em>
 reject the entire request with a 400 (Bad Request). If a client 
receives XML that is not well-formed in a response, then the client <em class="bcp14">MUST NOT</em> assume anything about the outcome of the executed method and <em class="bcp14">SHOULD</em> treat the server as malfunctioning.<a class="self" href="#rfc.section.8.2.p.4">¶</a></p></div><div id="rfc.section.8.2.p.5"><p>Note
 that processing XML submitted by an untrusted source may cause risks 
connected to privacy, security, and service quality (see <a href="#security.considerations" title="Security Considerations">Section&nbsp;20</a>). Servers <em class="bcp14">MAY</em>
 reject questionable requests (even though they consist of well-formed 
XML), for instance, with a 400 (Bad Request) status code and an optional
 response body explaining the problem.<a class="self" href="#rfc.section.8.2.p.5">¶</a></p></div></section><section id="url-handling"><h3 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a>&nbsp;<a href="#url-handling">URL Handling</a></h3><div id="rfc.section.8.3.p.1"><p>URLs appear in many places in requests and responses. Interoperability experience with <a href="#RFC2518" id="rfc.xref.RFC2518.2"><cite title="HTTP Extensions for Distributed Authoring -- WEBDAV">[RFC2518]</cite></a> showed that many clients parsing Multi-Status responses did not fully implement the full Reference Resolution defined in <a href="https://tools.ietf.org/html/rfc3986#section-5">Section 5</a> of <a href="#RFC3986" id="rfc.xref.RFC3986.5"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>.
 Thus, servers in particular need to be careful in handling URLs in 
responses, to ensure that clients have enough context to be able to 
interpret all the URLs. The rules in this section apply not only to 
resource URLs in the 'href' element in Multi-Status responses, but also 
to the Destination and If header resource URLs.<a class="self" href="#rfc.section.8.3.p.1">¶</a></p></div><div id="rfc.section.8.3.p.2"><p>The
 sender has a choice between two approaches: using a relative reference,
 which is resolved against the Request-URI, or a full URI. A server <em class="bcp14">MUST</em> ensure that every 'href' value within a Multi-Status response uses the same format.<a class="self" href="#rfc.section.8.3.p.2">¶</a></p></div><div id="simple-ref"><div id="rfc.section.8.3.p.3"><p> WebDAV only uses one form of relative reference in its extensions, the absolute path.<a class="self" href="#rfc.section.8.3.p.3">¶</a></p></div></div><div id="rfc.figure.u.11"><div id="rfc.iref.g.1"></div><pre class="inline">   <a href="#simple-ref" class="smpl">Simple-ref</a> = absolute-URI | ( path-absolute [ "?" query ] )      
</pre></div><div id="rfc.section.8.3.p.4"><p>The absolute-URI, path-absolute and query productions are defined in Sections <a href="https://tools.ietf.org/html/rfc3986#section-4.3" id="rfc.xref.RFC3986.6">4.3</a>, <a href="https://tools.ietf.org/html/rfc3986#section-3.3" id="rfc.xref.RFC3986.7">3.3</a>, and <a href="https://tools.ietf.org/html/rfc3986#section-3.4" id="rfc.xref.RFC3986.8">3.4</a> of <a href="#RFC3986" id="rfc.xref.RFC3986.9"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>.<a class="self" href="#rfc.section.8.3.p.4">¶</a></p></div><div id="rfc.section.8.3.p.5"><p>Within Simple-ref productions, senders <em class="bcp14">MUST NOT</em>: <a class="self" href="#rfc.section.8.3.p.5">¶</a></p><ul><li>use dot-segments ("." or ".."), or</li><li>have prefixes that do not match the Request-URI (using the comparison rules defined in <a href="https://tools.ietf.org/html/rfc2616#section-3.2.3">Section 3.2.3</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>).</li></ul></div><div id="rfc.section.8.3.p.6"><p>Identifiers for collections <em class="bcp14">SHOULD</em> end in a '/' character.<a class="self" href="#rfc.section.8.3.p.6">¶</a></p></div><section id="n-example---correct-url-handling"><h4 id="rfc.section.8.3.1"><a href="#rfc.section.8.3.1">8.3.1</a>&nbsp;<a href="#n-example---correct-url-handling">Example - Correct URL Handling</a></h4><div id="rfc.section.8.3.1.p.1" class="avoidbreakafter"><p>Consider
 the collection http://example.com/sample/ with the internal member URL 
http://example.com/sample/a%20test and the PROPFIND request below:<a class="self" href="#rfc.section.8.3.1.p.1">¶</a></p></div><div id="rfc.figure.u.12"><p>&gt;&gt;Request:</p><pre class="text2">  PROPFIND /sample/ HTTP/1.1
  Host: example.com
  Depth: 1          
</pre></div><div id="rfc.section.8.3.1.p.2"><p>In this case, the server should return two 'href' elements containing either <a class="self" href="#rfc.section.8.3.1.p.2">¶</a></p><ul><li>'http://example.com/sample/' and 'http://example.com/sample/a%20test', or</li><li>'/sample/' and '/sample/a%20test'</li></ul></div><div id="rfc.section.8.3.1.p.3"><p>Note
 that even though the server may be storing the member resource 
internally as 'a test', it has to be percent-encoded when used inside a 
URI reference (see <a href="https://tools.ietf.org/html/rfc3986#section-2.1">Section 2.1</a> of <a href="#RFC3986" id="rfc.xref.RFC3986.10"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>).
 Also note that a legal URI may still contain characters that need to be
 escaped within XML character data, such as the ampersand character.<a class="self" href="#rfc.section.8.3.1.p.3">¶</a></p></div></section></section><section id="n-required-bodies-in-requests"><h3 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a>&nbsp;<a href="#n-required-bodies-in-requests">Required Bodies in Requests</a></h3><div id="rfc.section.8.4.p.1"><p>Some of these new methods do not define bodies. Servers <em class="bcp14">MUST</em>
 examine all requests for a body, even when a body was not expected. In 
cases where a request body is present but would be ignored by a server, 
the server <em class="bcp14">MUST</em> reject the request with 415 
(Unsupported Media Type). This informs the client (which may have been 
attempting to use an extension) that the body could not be processed as 
the client intended.<a class="self" href="#rfc.section.8.4.p.1">¶</a></p></div></section><section id="http-headers"><h3 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a>&nbsp;<a href="#http-headers">HTTP Headers for Use in WebDAV</a></h3><div id="rfc.section.8.5.p.1"><p>HTTP
 defines many headers that can be used in WebDAV requests and responses.
 Not all of these are appropriate in all situations and some 
interactions may be undefined. Note that HTTP 1.1 requires the Date 
header in all responses if possible (see <a href="https://tools.ietf.org/html/rfc2616#section-14.18" id="rfc.xref.RFC2616.6">Section 14.18</a>, <a href="#RFC2616" id="rfc.xref.RFC2616.7"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>).<a class="self" href="#rfc.section.8.5.p.1">¶</a></p></div><div id="rfc.section.8.5.p.2"><p>The server <em class="bcp14">MUST</em> do authorization checks before checking any HTTP conditional header.<a class="self" href="#rfc.section.8.5.p.2">¶</a></p></div></section><section id="etag"><h3 id="rfc.section.8.6"><a href="#rfc.section.8.6">8.6</a>&nbsp;<a href="#etag">ETag</a></h3><div id="rfc.section.8.6.p.1"><p>HTTP
 1.1 recommends the use of ETags rather than modification dates, for 
cache control, and there are even stronger reasons to prefer ETags for 
authoring. Correct use of ETags is even more important in a distributed 
authoring environment, because ETags are necessary along with locks to 
avoid the lost-update problem. A client might fail to renew a lock, for 
example, when the lock times out and the client is accidentally offline 
or in the middle of a long upload. When a client fails to renew the 
lock, it's quite possible the resource can still be relocked and the 
user can go on editing, as long as no changes were made in the meantime.
 ETags are required for the client to be able to distinguish this case. 
Otherwise, the client is forced to ask the user whether to overwrite the
 resource on the server without even being able to tell the user if it 
has changed. Timestamps do not solve this problem nearly as well as 
ETags.<a class="self" href="#rfc.section.8.6.p.1">¶</a></p></div><div id="rfc.section.8.6.p.2"><p>Strong ETags are much more useful for authoring use cases than weak ETags (see <a href="https://tools.ietf.org/html/rfc2616#section-13.3.3">Section 13.3.3</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.8"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>).
 Semantic equivalence can be a useful concept but that depends on the 
document type and the application type, and interoperability might 
require some agreement or standard outside the scope of this 
specification and HTTP. Note also that weak ETags have certain 
restrictions in HTTP, e.g., these cannot be used in If-Match headers.<a class="self" href="#rfc.section.8.6.p.2">¶</a></p></div><div id="rfc.section.8.6.p.3"><p>Note
 that the meaning of an ETag in a PUT response is not clearly defined 
either in this document or in RFC 2616 (i.e., whether the ETag means 
that the resource is octet-for-octet equivalent to the body of the PUT 
request, or whether the server could have made minor changes in the 
formatting or content of the document upon storage). This is an HTTP 
issue, not purely a WebDAV issue.<a class="self" href="#rfc.section.8.6.p.3">¶</a></p></div><div id="rfc.section.8.6.p.4"><p>Because clients may be forced to prompt users or throw away changed content if the ETag changes, a WebDAV server <em class="bcp14">SHOULD NOT</em>
 change the ETag (or the Last-Modified time) for a resource that has an 
unchanged body and location. The ETag represents the state of the body 
or contents of the resource. There is no similar way to tell if 
properties have changed.<a class="self" href="#rfc.section.8.6.p.4">¶</a></p></div></section><section id="including.error.reponse.bodies"><h3 id="rfc.section.8.7"><a href="#rfc.section.8.7">8.7</a>&nbsp;<a href="#including.error.reponse.bodies">Including Error Response Bodies</a></h3><div id="rfc.section.8.7.p.1"><p>HTTP
 and WebDAV did not use the bodies of most error responses for 
machine-parsable information until the specification for Versioning 
Extensions to WebDAV introduced a mechanism to include more specific 
information in the body of an error response (<a href="https://tools.ietf.org/html/rfc3253#section-1.6">Section 1.6</a> of <a href="#RFC3253" id="rfc.xref.RFC3253.2"><cite title="Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)">[RFC3253]</cite></a>).
 The error body mechanism is appropriate to use with any error response 
that may take a body but does not already have a body defined. The 
mechanism is particularly appropriate when a status code can mean many 
things (for example, 400 Bad Request can mean required headers are 
missing, headers are incorrectly formatted, or much more). This error 
body mechanism is covered in <a href="#precondition.postcondition.xml.elements" title="Precondition/Postcondition XML Elements">Section&nbsp;16</a>.<a class="self" href="#rfc.section.8.7.p.1">¶</a></p></div></section><section id="cache-control"><h3 id="rfc.section.8.8"><a href="#rfc.section.8.8">8.8</a>&nbsp;<a href="#cache-control">Impact of Namespace Operations on Cache Validators</a></h3><div id="rfc.section.8.8.p.1" class="avoidbreakafter"><p>Note that the HTTP response headers "Etag" and "Last-Modified" (see <a href="#RFC2616" id="rfc.xref.RFC2616.9"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, Sections <a href="https://tools.ietf.org/html/rfc2616#section-14.19" id="rfc.xref.RFC2616.10">14.19</a> and <a href="https://tools.ietf.org/html/rfc2616#section-14.29" id="rfc.xref.RFC2616.11">14.29</a>)
 are defined per URL (not per resource), and are used by clients for 
caching. Therefore servers must ensure that executing any operation that
 affects the URL namespace (such as COPY, MOVE, DELETE, PUT, or MKCOL) 
does preserve their semantics, in particular:<a class="self" href="#rfc.section.8.8.p.1">¶</a></p></div><div id="rfc.section.8.8.p.2"><ul><li>For any given URL, the "Last-Modified" value <em class="bcp14">MUST</em> increment every time the representation returned upon GET changes (within the limits of timestamp resolution).</li><li>For any given URL, an "ETag" value <em class="bcp14">MUST NOT</em> be reused for different representations returned by GET.</li></ul></div><div id="rfc.section.8.8.p.3"><p>In practice this means that servers<a class="self" href="#rfc.section.8.8.p.3">¶</a></p></div><div id="rfc.section.8.8.p.4"><ul><li>might
 have to increment "Last-Modified" timestamps for every resource inside 
the destination namespace of a namespace operation unless it can do so 
more selectively, and</li><li>similarly, might have to re-assign "ETag" 
values for these resources (unless the server allocates entity tags in a
 way so that they are unique across the whole URL namespace managed by 
the server).</li></ul></div><div id="rfc.section.8.8.p.5"><p>Note that 
these considerations also apply to specific use cases, such as using PUT
 to create a new resource at a URL that has been mapped before, but has 
been deleted since then.<a class="self" href="#rfc.section.8.8.p.5">¶</a></p></div><div id="rfc.section.8.8.p.6"><p>Finally,
 WebDAV properties (such as DAV:getetag and DAV: getlastmodified) that 
inherit their semantics from HTTP headers must behave accordingly.<a class="self" href="#rfc.section.8.8.p.6">¶</a></p></div></section></section><section id="http.methods.for.distributed.authoring"><h2 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a href="#http.methods.for.distributed.authoring">HTTP Methods for Distributed Authoring</a></h2><section id="METHOD_PROPFIND"><h3 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a>&nbsp;<a href="#METHOD_PROPFIND">PROPFIND Method</a></h3><div id="rfc.section.9.1.p.1"><p>The
 PROPFIND method retrieves properties defined on the resource identified
 by the Request-URI, if the resource does not have any internal members,
 or on the resource identified by the Request-URI and potentially its 
member resources, if the resource is a collection that has internal 
member URLs. All DAV-compliant resources <em class="bcp14">MUST</em> support the PROPFIND method and the propfind XML element (<a href="#ELEMENT_propfind" title="propfind XML Element">Section&nbsp;14.20</a>) along with all XML elements defined for use with that element.<a class="self" href="#rfc.section.9.1.p.1">¶</a></p></div><div id="rfc.section.9.1.p.2"><p>A client <em class="bcp14">MUST</em> submit a Depth header with a value of "0", "1", or "infinity" with a PROPFIND request. Servers <em class="bcp14">MUST</em> support "0" and "1" depth requests on WebDAV-compliant resources and <em class="bcp14">SHOULD</em> support "infinity" requests. In practice, support for infinite-depth requests <em class="bcp14">MAY</em> be disabled, due to the performance and security concerns associated with this behavior. Servers <em class="bcp14">SHOULD</em> treat a request without a Depth header as if a "Depth: infinity" header was included.<a class="self" href="#rfc.section.9.1.p.2">¶</a></p></div><div id="rfc.section.9.1.p.3" class="avoidbreakafter"><p>A
 client may submit a 'propfind' XML element in the body of the request 
method describing what information is being requested. It is possible 
to:<a class="self" href="#rfc.section.9.1.p.3">¶</a></p></div><div id="rfc.section.9.1.p.4"><ul><li>Request
 particular property values, by naming the properties desired within the
 'prop' element (the ordering of properties in here <em class="bcp14">MAY</em> be ignored by the server),</li><li>Request
 property values for those properties defined in this specification (at a
 minimum) plus dead properties, by using the 'allprop' element (the 
'include' element can be used with 'allprop' to instruct the server to 
also include additional live properties that may not have been returned 
otherwise),</li><li>Request a list of names of all the properties defined on the resource, by using the 'propname' element.</li></ul></div><div id="rfc.section.9.1.p.5"><p>A client may choose not to submit a request body. An empty PROPFIND request body <em class="bcp14">MUST</em> be treated as if it were an 'allprop' request.<a class="self" href="#rfc.section.9.1.p.5">¶</a></p></div><div id="rfc.section.9.1.p.6"><p>Note
 that 'allprop' does not return values for all live properties. WebDAV 
servers increasingly have expensively-calculated or lengthy properties 
(see <a href="#RFC3253" id="rfc.xref.RFC3253.3"><cite title="Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)">[RFC3253]</cite></a> and <a href="#RFC3744" id="rfc.xref.RFC3744.2"><cite title="Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol">[RFC3744]</cite></a>)
 and do not return all properties already. Instead, WebDAV clients can 
use propname requests to discover what live properties exist, and 
request named properties when retrieving values. For a live property 
defined elsewhere, that definition can specify whether or not that live 
property would be returned in 'allprop' requests.<a class="self" href="#rfc.section.9.1.p.6">¶</a></p></div><div id="rfc.section.9.1.p.7"><p>All servers <em class="bcp14">MUST</em>
 support returning a response of content type text/xml or 
application/xml that contains a multistatus XML element that describes 
the results of the attempts to retrieve the various properties.<a class="self" href="#rfc.section.9.1.p.7">¶</a></p></div><div id="rfc.section.9.1.p.8"><p>If there is an error retrieving a property, then a proper error result <em class="bcp14">MUST</em> be included in the response. A request to retrieve the value of a property that does not exist is an error and <em class="bcp14">MUST</em> be noted with a 'response' XML element that contains a 404 (Not Found) status value.<a class="self" href="#rfc.section.9.1.p.8">¶</a></p></div><div id="rfc.section.9.1.p.9"><p>Consequently, the 'multistatus' XML element for a collection resource <em class="bcp14">MUST</em> include a 'response' XML element for each member URL of the collection, to whatever depth was requested. It <em class="bcp14">SHOULD NOT</em> include any 'response' elements for resources that are not WebDAV-compliant. Each 'response' element <em class="bcp14">MUST</em>
 contain an 'href' element that contains the URL of the resource on 
which the properties in the prop XML element are defined. Results for a 
PROPFIND on a collection resource are returned as a flat list whose 
order of entries is not significant. Note that a resource may have only 
one value for a property of a given name, so the property may only show 
up once in PROPFIND responses.<a class="self" href="#rfc.section.9.1.p.9">¶</a></p></div><div id="rfc.section.9.1.p.10"><p>Properties
 may be subject to access control. In the case of 'allprop' and 
'propname' requests, if a principal does not have the right to know 
whether a particular property exists, then the property <em class="bcp14">MAY</em> be silently excluded from the response.<a class="self" href="#rfc.section.9.1.p.10">¶</a></p></div><div id="rfc.section.9.1.p.11"><p>Some PROPFIND results <em class="bcp14">MAY</em>
 be cached, with care, as there is no cache validation mechanism for 
most properties. This method is both safe and idempotent (see <a href="https://tools.ietf.org/html/rfc2616#section-9.1">Section 9.1</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.12"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>).<a class="self" href="#rfc.section.9.1.p.11">¶</a></p></div><section id="n-propfind-status-codes"><h4 id="rfc.section.9.1.1"><a href="#rfc.section.9.1.1">9.1.1</a>&nbsp;<a href="#n-propfind-status-codes">PROPFIND Status Codes</a></h4><div id="rfc.section.9.1.1.p.1"><p>This
 section, as with similar sections for other methods, provides some 
guidance on error codes and preconditions or postconditions (defined in <a href="#precondition.postcondition.xml.elements" title="Precondition/Postcondition XML Elements">Section&nbsp;16</a>) that might be particularly useful with PROPFIND.<a class="self" href="#rfc.section.9.1.1.p.1">¶</a></p></div><div id="rfc.section.9.1.1.p.2"><p>403 Forbidden - A server <em class="bcp14">MAY</em> reject PROPFIND requests on collections with depth header of "Infinity", in which case it <em class="bcp14">SHOULD</em> use this error with the precondition code 'propfind-finite-depth' inside the error body.<a class="self" href="#rfc.section.9.1.1.p.2">¶</a></p></div></section><section id="PROPFIND-multistatus"><h4 id="rfc.section.9.1.2"><a href="#rfc.section.9.1.2">9.1.2</a>&nbsp;<a href="#PROPFIND-multistatus">Status Codes for Use in 'propstat' Element</a></h4><div id="rfc.section.9.1.2.p.1"><p>In PROPFIND responses, information about individual properties is returned inside 'propstat' elements (see <a href="#ELEMENT_propstat" title="propstat XML Element">Section&nbsp;14.22</a>),
 each containing an individual 'status' element containing information 
about the properties appearing in it. The list below summarizes the most
 common status codes used inside 'propstat'; however, clients should be 
prepared to handle other 2/3/4/5xx series status codes as well.<a class="self" href="#rfc.section.9.1.2.p.1">¶</a></p></div><div id="rfc.section.9.1.2.p.2"><p>200 OK - A property exists and/or its value is successfully returned.<a class="self" href="#rfc.section.9.1.2.p.2">¶</a></p></div><div id="rfc.section.9.1.2.p.3"><p>401 Unauthorized - The property cannot be viewed without appropriate authorization.<a class="self" href="#rfc.section.9.1.2.p.3">¶</a></p></div><div id="rfc.section.9.1.2.p.4"><p>403 Forbidden - The property cannot be viewed regardless of authentication.<a class="self" href="#rfc.section.9.1.2.p.4">¶</a></p></div><div id="rfc.section.9.1.2.p.5"><p>404 Not Found - The property does not exist.<a class="self" href="#rfc.section.9.1.2.p.5">¶</a></p></div></section><section id="n-example---retrieving-named-properties"><h4 id="rfc.section.9.1.3"><a href="#rfc.section.9.1.3">9.1.3</a>&nbsp;<a href="#n-example---retrieving-named-properties">Example - Retrieving Named Properties</a></h4><div id="rfc.figure.u.13"><p>&gt;&gt;Request</p><pre class="text2">  PROPFIND /file HTTP/1.1 
  Host: www.example.com 
  Content-type: application/xml; charset="utf-8" 
  Content-Length: xxxx 
    
  &lt;?xml version="1.0" encoding="utf-8" ?&gt; 
  &lt;D:propfind xmlns:D="DAV:"&gt; 
    &lt;D:prop xmlns:R="http://ns.example.com/boxschema/"&gt; 
      &lt;R:bigbox/&gt; 
      &lt;R:author/&gt; 
      &lt;R:DingALing/&gt; 
      &lt;R:Random/&gt; 
    &lt;/D:prop&gt; 
  &lt;/D:propfind&gt; 
</pre></div><div id="rfc.figure.u.14"><p>&gt;&gt;Response</p><pre class="text">  HTTP/1.1 207 Multi-Status 
  Content-Type: application/xml; charset="utf-8" 
  Content-Length: xxxx 
    
  &lt;?xml version="1.0" encoding="utf-8" ?&gt; 
  &lt;D:multistatus xmlns:D="DAV:"&gt; 
    &lt;D:response xmlns:R="http://ns.example.com/boxschema/"&gt; 
      &lt;D:href&gt;http://www.example.com/file&lt;/D:href&gt; 
      &lt;D:propstat&gt; 
        &lt;D:prop&gt; 
          &lt;R:bigbox&gt; 
            &lt;R:BoxType&gt;Box type A&lt;/R:BoxType&gt; 
          &lt;/R:bigbox&gt; 
          &lt;R:author&gt; 
            &lt;R:Name&gt;J.J. Johnson&lt;/R:Name&gt; 
          &lt;/R:author&gt; 
        &lt;/D:prop&gt; 
        &lt;D:status&gt;HTTP/1.1 200 OK&lt;/D:status&gt; 
      &lt;/D:propstat&gt; 
      &lt;D:propstat&gt; 
        &lt;D:prop&gt;&lt;R:DingALing/&gt;&lt;R:Random/&gt;&lt;/D:prop&gt; 
        &lt;D:status&gt;HTTP/1.1 403 Forbidden&lt;/D:status&gt; 
        &lt;D:responsedescription&gt; The user does not have access to the 
   DingALing property. 
        &lt;/D:responsedescription&gt; 
      &lt;/D:propstat&gt; 
    &lt;/D:response&gt; 
    &lt;D:responsedescription&gt; There has been an access violation error.
    &lt;/D:responsedescription&gt; 
  &lt;/D:multistatus&gt; 
</pre></div><div id="rfc.section.9.1.3.p.1"><p>In this example, PROPFIND
 is executed on a non-collection resource http://www.example.com/file. 
The propfind XML element specifies the name of four properties whose 
values are being requested. In this case, only two properties were 
returned, since the principal issuing the request did not have 
sufficient access rights to see the third and fourth properties.<a class="self" href="#rfc.section.9.1.3.p.1">¶</a></p></div></section><section><h4 id="rfc.section.9.1.4"><a href="#rfc.section.9.1.4">9.1.4</a>&nbsp;Example - Using 'propname' to Retrieve All Property Names</h4><div id="rfc.figure.u.15"><p>&gt;&gt;Request</p><pre class="text2">  PROPFIND /container/ HTTP/1.1 
  Host: www.example.com 
  Content-Type: application/xml; charset="utf-8" 
  Content-Length: xxxx 
      
  &lt;?xml version="1.0" encoding="utf-8" ?&gt; 
  &lt;propfind xmlns="DAV:"&gt; 
    &lt;propname/&gt; 
  &lt;/propfind&gt; 
</pre></div><div id="rfc.figure.u.16"><p>&gt;&gt;Response</p><pre class="text">  HTTP/1.1 207 Multi-Status 
  Content-Type: application/xml; charset="utf-8" 
  Content-Length: xxxx 
      
  &lt;?xml version="1.0" encoding="utf-8" ?&gt; 
  &lt;multistatus xmlns="DAV:"&gt; 
    &lt;response&gt; 
      &lt;href&gt;http://www.example.com/container/&lt;/href&gt; 
      &lt;propstat&gt; 
        &lt;prop xmlns:R="http://ns.example.com/boxschema/"&gt; 
          &lt;R:bigbox/&gt; 
          &lt;R:author/&gt; 
          &lt;creationdate/&gt; 
          &lt;displayname/&gt; 
          &lt;resourcetype/&gt; 
          &lt;supportedlock/&gt; 
        &lt;/prop&gt; 
        &lt;status&gt;HTTP/1.1 200 OK&lt;/status&gt; 
      &lt;/propstat&gt; 
    &lt;/response&gt; 
    &lt;response&gt; 
      &lt;href&gt;http://www.example.com/container/front.html&lt;/href&gt; 
      &lt;propstat&gt; 
        &lt;prop xmlns:R="http://ns.example.com/boxschema/"&gt; 
          &lt;R:bigbox/&gt; 
          &lt;creationdate/&gt; 
          &lt;displayname/&gt; 
          &lt;getcontentlength/&gt; 
          &lt;getcontenttype/&gt; 
          &lt;getetag/&gt; 
          &lt;getlastmodified/&gt; 
          &lt;resourcetype/&gt; 
          &lt;supportedlock/&gt; 
        &lt;/prop&gt; 
        &lt;status&gt;HTTP/1.1 200 OK&lt;/status&gt; 
      &lt;/propstat&gt; 
    &lt;/response&gt; 
  &lt;/multistatus&gt; 
</pre></div><div id="rfc.section.9.1.4.p.1"><p>In this example, PROPFIND
 is invoked on the collection resource 
http://www.example.com/container/, with a propfind XML element 
containing the propname XML element, meaning the name of all properties 
should be returned. Since no Depth header is present, it assumes its 
default value of "infinity", meaning the name of the properties on the 
collection and all its descendants should be returned.<a class="self" href="#rfc.section.9.1.4.p.1">¶</a></p></div><div id="rfc.section.9.1.4.p.2"><p>Consistent
 with the previous example, resource http://www.example.com/container/ 
has six properties defined on it: bigbox and author in the 
"http://ns.example.com/boxschema/" namespace, and creationdate, 
displayname, resourcetype, and supportedlock in the "DAV:" namespace.<a class="self" href="#rfc.section.9.1.4.p.2">¶</a></p></div><div id="rfc.section.9.1.4.p.3"><p>The
 resource http://www.example.com/container/index.html, a member of the 
"container" collection, has nine properties defined on it, bigbox in the
 "http://ns.example.com/boxschema/" namespace and creationdate, 
displayname, getcontentlength, getcontenttype, getetag, getlastmodified,
 resourcetype, and supportedlock in the "DAV:" namespace.<a class="self" href="#rfc.section.9.1.4.p.3">¶</a></p></div><div id="rfc.section.9.1.4.p.4"><p>This
 example also demonstrates the use of XML namespace scoping and the 
default namespace. Since the "xmlns" attribute does not contain a 
prefix, the namespace applies by default to all enclosed elements. 
Hence, all elements that do not explicitly state the namespace to which 
they belong are members of the "DAV:" namespace.<a class="self" href="#rfc.section.9.1.4.p.4">¶</a></p></div></section><section><h4 id="rfc.section.9.1.5"><a href="#rfc.section.9.1.5">9.1.5</a>&nbsp;Example - Using So-called 'allprop'</h4><div id="rfc.section.9.1.5.p.1"><p>Note
 that 'allprop', despite its name, which remains for 
backward-compatibility, does not return every property, but only dead 
properties and the live properties defined in this specification.<a class="self" href="#rfc.section.9.1.5.p.1">¶</a></p></div><div id="rfc.figure.u.17"><p>&gt;&gt;Request</p><pre class="text2">  PROPFIND /container/ HTTP/1.1
  Host: www.example.com
  Depth: 1
  Content-Type: application/xml; charset="utf-8"
  Content-Length: xxxx

  &lt;?xml version="1.0" encoding="utf-8" ?&gt;
  &lt;D:propfind xmlns:D="DAV:"&gt;
    &lt;D:allprop/&gt;
  &lt;/D:propfind&gt;
</pre></div><div id="rfc.figure.u.18"><p>&gt;&gt;Response</p><pre class="text">  HTTP/1.1 207 Multi-Status
  Content-Type: application/xml; charset="utf-8"
  Content-Length: xxxx

  &lt;?xml version="1.0" encoding="utf-8" ?&gt;
  &lt;D:multistatus xmlns:D="DAV:"&gt;
    &lt;D:response&gt;
      &lt;D:href&gt;/container/&lt;/D:href&gt;
      &lt;D:propstat&gt;
        &lt;D:prop xmlns:R="http://ns.example.com/boxschema/"&gt;
          &lt;R:bigbox&gt;&lt;R:BoxType&gt;Box type A&lt;/R:BoxType&gt;&lt;/R:bigbox&gt;
          &lt;R:author&gt;&lt;R:Name&gt;Hadrian&lt;/R:Name&gt;&lt;/R:author&gt;
          &lt;D:creationdate&gt;1997-12-01T17:42:21-08:00&lt;/D:creationdate&gt;
          &lt;D:displayname&gt;Example collection&lt;/D:displayname&gt;
          &lt;D:resourcetype&gt;&lt;D:collection/&gt;&lt;/D:resourcetype&gt;
          &lt;D:supportedlock&gt;
            &lt;D:lockentry&gt;
              &lt;D:lockscope&gt;&lt;D:exclusive/&gt;&lt;/D:lockscope&gt;
              &lt;D:locktype&gt;&lt;D:write/&gt;&lt;/D:locktype&gt;
            &lt;/D:lockentry&gt;
            &lt;D:lockentry&gt;
              &lt;D:lockscope&gt;&lt;D:shared/&gt;&lt;/D:lockscope&gt;
              &lt;D:locktype&gt;&lt;D:write/&gt;&lt;/D:locktype&gt;
            &lt;/D:lockentry&gt;
          &lt;/D:supportedlock&gt;
        &lt;/D:prop&gt;
        &lt;D:status&gt;HTTP/1.1 200 OK&lt;/D:status&gt;
      &lt;/D:propstat&gt;
    &lt;/D:response&gt;
    &lt;D:response&gt;
      &lt;D:href&gt;/container/front.html&lt;/D:href&gt;
      &lt;D:propstat&gt;
        &lt;D:prop xmlns:R="http://ns.example.com/boxschema/"&gt;
          &lt;R:bigbox&gt;&lt;R:BoxType&gt;Box type B&lt;/R:BoxType&gt;
          &lt;/R:bigbox&gt;
          &lt;D:creationdate&gt;1997-12-01T18:27:21-08:00&lt;/D:creationdate&gt;
          &lt;D:displayname&gt;Example HTML resource&lt;/D:displayname&gt;
          &lt;D:getcontentlength&gt;4525&lt;/D:getcontentlength&gt;
          &lt;D:getcontenttype&gt;text/html&lt;/D:getcontenttype&gt;
          &lt;D:getetag&gt;"zzyzx"&lt;/D:getetag&gt;
          &lt;D:getlastmodified
            &gt;Mon, 12 Jan 1998 09:25:56 GMT&lt;/D:getlastmodified&gt;
          &lt;D:resourcetype/&gt;
          &lt;D:supportedlock&gt;
            &lt;D:lockentry&gt;
              &lt;D:lockscope&gt;&lt;D:exclusive/&gt;&lt;/D:lockscope&gt;
              &lt;D:locktype&gt;&lt;D:write/&gt;&lt;/D:locktype&gt;
            &lt;/D:lockentry&gt;
            &lt;D:lockentry&gt;
              &lt;D:lockscope&gt;&lt;D:shared/&gt;&lt;/D:lockscope&gt;
              &lt;D:locktype&gt;&lt;D:write/&gt;&lt;/D:locktype&gt;
            &lt;/D:lockentry&gt;
          &lt;/D:supportedlock&gt;
        &lt;/D:prop&gt;
        &lt;D:status&gt;HTTP/1.1 200 OK&lt;/D:status&gt;
      &lt;/D:propstat&gt;
    &lt;/D:response&gt;
  &lt;/D:multistatus&gt;
</pre></div><div id="rfc.section.9.1.5.p.2"><p>In this example, PROPFIND
 was invoked on the resource http://www.example.com/container/ with a 
Depth header of 1, meaning the request applies to the resource and its 
children, and a propfind XML element containing the allprop XML element,
 meaning the request should return the name and value of all the dead 
properties defined on the resources, plus the name and value of all the 
properties defined in this specification. This example illustrates the 
use of relative references in the 'href' elements of the response.<a class="self" href="#rfc.section.9.1.5.p.2">¶</a></p></div><div id="rfc.section.9.1.5.p.3"><p>The
 resource http://www.example.com/container/ has six properties defined 
on it: 'bigbox' and 'author in the "http://ns.example.com/boxschema/" 
namespace, DAV:creationdate, DAV:displayname, DAV:resourcetype, and 
DAV:supportedlock.<a class="self" href="#rfc.section.9.1.5.p.3">¶</a></p></div><div id="rfc.section.9.1.5.p.4"><p>The last four properties are WebDAV-specific, defined in <a href="#dav.properties" title="DAV Properties">Section&nbsp;15</a>.
 Since GET is not supported on this resource, the get* properties (e.g.,
 DAV:getcontentlength) are not defined on this resource. The 
WebDAV-specific properties assert that "container" was created on 
December 1, 1997, at 5:42:21PM, in a time zone 8 hours west of GMT 
(DAV:creationdate), has a name of "Example collection" 
(DAV:displayname), a collection resource type (DAV:resourcetype), and 
supports exclusive write and shared write locks (DAV:supportedlock).<a class="self" href="#rfc.section.9.1.5.p.4">¶</a></p></div><div id="rfc.section.9.1.5.p.5" class="avoidbreakafter"><p>The resource http://www.example.com/container/front.html has nine properties defined on it:<a class="self" href="#rfc.section.9.1.5.p.5">¶</a></p></div><div id="rfc.section.9.1.5.p.6"><p>'bigbox'
 in the "http://ns.example.com/boxschema/" namespace (another instance 
of the "bigbox" property type), DAV:creationdate, DAV:displayname, 
DAV:getcontentlength, DAV:getcontenttype, DAV:getetag, 
DAV:getlastmodified, DAV:resourcetype, and DAV:supportedlock.<a class="self" href="#rfc.section.9.1.5.p.6">¶</a></p></div><div id="rfc.section.9.1.5.p.7"><p>The
 DAV-specific properties assert that "front.html" was created on 
December 1, 1997, at 6:27:21PM, in a time zone 8 hours west of GMT 
(DAV:creationdate), has a name of "Example HTML resource" 
(DAV:displayname), a content length of 4525 bytes 
(DAV:getcontentlength), a MIME type of "text/html" (DAV:getcontenttype),
 an entity tag of "zzyzx" (DAV:getetag), was last modified on Monday, 
January 12, 1998, at 09:25:56 GMT (DAV:getlastmodified), has an empty 
resource type, meaning that it is not a collection (DAV:resourcetype), 
and supports both exclusive write and shared write locks 
(DAV:supportedlock).<a class="self" href="#rfc.section.9.1.5.p.7">¶</a></p></div></section><section><h4 id="rfc.section.9.1.6"><a href="#rfc.section.9.1.6">9.1.6</a>&nbsp;Example - Using 'allprop' with 'include'</h4><div id="rfc.figure.u.19"><p>&gt;&gt;Request</p><pre class="text2">  PROPFIND /mycol/ HTTP/1.1 
  Host: www.example.com 
  Depth: 1 
  Content-Type: application/xml; charset="utf-8" 
  Content-Length: xxxx 
      
  &lt;?xml version="1.0" encoding="utf-8" ?&gt; 
  &lt;D:propfind xmlns:D="DAV:"&gt; 
    &lt;D:allprop/&gt;
    &lt;D:include&gt; 
      &lt;D:supported-live-property-set/&gt; 
      &lt;D:supported-report-set/&gt; 
    &lt;/D:include&gt; 
  &lt;/D:propfind&gt; 
</pre></div><div id="rfc.section.9.1.6.p.1"><p>In this example, PROPFIND
 is executed on the resource http://www.example.com/mycol/ and its 
internal member resources. The client requests the values of all live 
properties defined in this specification, plus all dead properties, plus
 two more live properties defined in <a href="#RFC3253" id="rfc.xref.RFC3253.4"><cite title="Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)">[RFC3253]</cite></a>. The response is not shown.<a class="self" href="#rfc.section.9.1.6.p.1">¶</a></p></div></section></section><section id="METHOD_PROPPATCH"><h3 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a>&nbsp;<a href="#METHOD_PROPPATCH">PROPPATCH Method</a></h3><div id="rfc.section.9.2.p.1"><p>The
 PROPPATCH method processes instructions specified in the request body 
to set and/or remove properties defined on the resource identified by 
the Request-URI.<a class="self" href="#rfc.section.9.2.p.1">¶</a></p></div><div id="rfc.section.9.2.p.2"><p>All DAV-compliant resources <em class="bcp14">MUST</em> support the PROPPATCH method and <em class="bcp14">MUST</em>
 process instructions that are specified using the propertyupdate, set, 
and remove XML elements. Execution of the directives in this method is, 
of course, subject to access control constraints. DAV-compliant 
resources <em class="bcp14">SHOULD</em> support the setting of arbitrary dead properties.<a class="self" href="#rfc.section.9.2.p.2">¶</a></p></div><div id="rfc.section.9.2.p.3"><p>The request message body of a PROPPATCH method <em class="bcp14">MUST</em> contain the propertyupdate XML element.<a class="self" href="#rfc.section.9.2.p.3">¶</a></p></div><div id="rfc.section.9.2.p.4"><p>Servers <em class="bcp14">MUST</em> process PROPPATCH instructions in document order (an exception to the normal rule that ordering is irrelevant). Instructions <em class="bcp14">MUST</em> either all be executed or none executed. Thus, if any error occurs during processing, all executed instructions <em class="bcp14">MUST</em>
 be undone and a proper error result returned. Instruction processing 
details can be found in the definition of the set and remove 
instructions in Sections <a href="#ELEMENT_remove" title="remove XML Element">14.23</a> and <a href="#ELEMENT_set" title="set XML Element">14.26</a>.<a class="self" href="#rfc.section.9.2.p.4">¶</a></p></div><div id="rfc.section.9.2.p.5"><p>If
 a server attempts to make any of the property changes in a PROPPATCH 
request (i.e., the request is not rejected for high-level errors before 
processing the body), the response <em class="bcp14">MUST</em> be a Multi-Status response as described in <a href="#PROPPATCH-status" title="Status Codes for Use in 'propstat' Element">Section&nbsp;9.2.1</a>.<a class="self" href="#rfc.section.9.2.p.5">¶</a></p></div><div id="rfc.section.9.2.p.6"><p>This method is idempotent, but not safe (see <a href="https://tools.ietf.org/html/rfc2616#section-9.1">Section 9.1</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.13"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>). Responses to this method <em class="bcp14">MUST NOT</em> be cached.<a class="self" href="#rfc.section.9.2.p.6">¶</a></p></div><section id="PROPPATCH-status"><h4 id="rfc.section.9.2.1"><a href="#rfc.section.9.2.1">9.2.1</a>&nbsp;<a href="#PROPPATCH-status">Status Codes for Use in 'propstat' Element</a></h4><div id="rfc.section.9.2.1.p.1"><p>In PROPPATCH responses, information about individual properties is returned inside 'propstat' elements (see <a href="#ELEMENT_propstat" title="propstat XML Element">Section&nbsp;14.22</a>),
 each containing an individual 'status' element containing information 
about the properties appearing in it. The list below summarizes the most
 common status codes used inside 'propstat'; however, clients should be 
prepared to handle other 2/3/4/5xx series status codes as well.<a class="self" href="#rfc.section.9.2.1.p.1">¶</a></p></div><div id="rfc.section.9.2.1.p.2"><p>200
 (OK) - The property set or change succeeded. Note that if this appears 
for one property, it appears for every property in the response, due to 
the atomicity of PROPPATCH.<a class="self" href="#rfc.section.9.2.1.p.2">¶</a></p></div><div id="rfc.section.9.2.1.p.3"><p>403 (Forbidden) - The client, for reasons the server chooses not to specify, cannot alter one of the properties.<a class="self" href="#rfc.section.9.2.1.p.3">¶</a></p></div><div id="rfc.section.9.2.1.p.4"><p>403 (Forbidden): The client has attempted to set a protected property, such as DAV:getetag. If returning this error, the server <em class="bcp14">SHOULD</em> use the precondition code 'cannot-modify-protected-property' inside the response body.<a class="self" href="#rfc.section.9.2.1.p.4">¶</a></p></div><div id="rfc.section.9.2.1.p.5"><p>409 (Conflict) - The client has provided a value whose semantics are not appropriate for the property.<a class="self" href="#rfc.section.9.2.1.p.5">¶</a></p></div><div id="rfc.section.9.2.1.p.6"><p>424 (Failed Dependency) - The property change could not be made because of another property change that failed.<a class="self" href="#rfc.section.9.2.1.p.6">¶</a></p></div><div id="rfc.section.9.2.1.p.7"><p>507 (Insufficient Storage) - The server did not have sufficient space to record the property.<a class="self" href="#rfc.section.9.2.1.p.7">¶</a></p></div></section><section id="n-example---proppatch"><h4 id="rfc.section.9.2.2"><a href="#rfc.section.9.2.2">9.2.2</a>&nbsp;<a href="#n-example---proppatch">Example - PROPPATCH</a></h4><div id="rfc.figure.u.20"><p>&gt;&gt;Request</p><pre class="text2">  PROPPATCH /bar.html HTTP/1.1 
  Host: www.example.com 
  Content-Type: application/xml; charset="utf-8" 
  Content-Length: xxxx 

  &lt;?xml version="1.0" encoding="utf-8" ?&gt; 
  &lt;D:propertyupdate xmlns:D="DAV:"   
          xmlns:Z="http://ns.example.com/standards/z39.50/"&gt;
    &lt;D:set&gt; 
      &lt;D:prop&gt; 
        &lt;Z:Authors&gt; 
          &lt;Z:Author&gt;Jim Whitehead&lt;/Z:Author&gt; 
          &lt;Z:Author&gt;Roy Fielding&lt;/Z:Author&gt; 
        &lt;/Z:Authors&gt; 
      &lt;/D:prop&gt; 
    &lt;/D:set&gt; 
    &lt;D:remove&gt; 
      &lt;D:prop&gt;&lt;Z:Copyright-Owner/&gt;&lt;/D:prop&gt; 
    &lt;/D:remove&gt; 
  &lt;/D:propertyupdate&gt; 
</pre></div><div id="rfc.figure.u.21"><p>&gt;&gt;Response</p><pre class="text">  HTTP/1.1 207 Multi-Status 
  Content-Type: application/xml; charset="utf-8" 
  Content-Length: xxxx 
  
  &lt;?xml version="1.0" encoding="utf-8" ?&gt; 
  &lt;D:multistatus xmlns:D="DAV:" 
          xmlns:Z="http://ns.example.com/standards/z39.50/"&gt; 
    &lt;D:response&gt; 
      &lt;D:href&gt;http://www.example.com/bar.html&lt;/D:href&gt; 
      &lt;D:propstat&gt; 
        &lt;D:prop&gt;&lt;Z:Authors/&gt;&lt;/D:prop&gt; 
        &lt;D:status&gt;HTTP/1.1 424 Failed Dependency&lt;/D:status&gt; 
      &lt;/D:propstat&gt; 
      &lt;D:propstat&gt; 
        &lt;D:prop&gt;&lt;Z:Copyright-Owner/&gt;&lt;/D:prop&gt; 
        &lt;D:status&gt;HTTP/1.1 409 Conflict&lt;/D:status&gt; 
      &lt;/D:propstat&gt; 
      &lt;D:responsedescription&gt; Copyright Owner cannot be deleted or 
        altered.&lt;/D:responsedescription&gt; 
    &lt;/D:response&gt; 
  &lt;/D:multistatus&gt; 
</pre></div><div id="rfc.section.9.2.2.p.1"><p>In this example, the 
client requests the server to set the value of the "Authors" property in
 the "http://ns.example.com/standards/z39.50/" namespace, and to remove 
the property "Copyright-Owner" in the same namespace. Since the 
Copyright-Owner property could not be removed, no property modifications
 occur. The 424 (Failed Dependency) status code for the Authors property
 indicates this action would have succeeded if it were not for the 
conflict with removing the Copyright-Owner property.<a class="self" href="#rfc.section.9.2.2.p.1">¶</a></p></div></section></section><section id="METHOD_MKCOL"><h3 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a>&nbsp;<a href="#METHOD_MKCOL">MKCOL Method</a></h3><div id="rfc.section.9.3.p.1"><p>MKCOL
 creates a new collection resource at the location specified by the 
Request-URI. If the Request-URI is already mapped to a resource, then 
the MKCOL <em class="bcp14">MUST</em> fail. During MKCOL processing, a server <em class="bcp14">MUST</em>
 make the Request-URI an internal member of its parent collection, 
unless the Request-URI is "/". If no such ancestor exists, the method <em class="bcp14">MUST</em> fail. When the MKCOL operation creates a new collection resource, all ancestors <em class="bcp14">MUST</em> already exist, or the method <em class="bcp14">MUST</em>
 fail with a 409 (Conflict) status code. For example, if a request to 
create collection /a/b/c/d/ is made, and /a/b/c/ does not exist, the 
request must fail.<a class="self" href="#rfc.section.9.3.p.1">¶</a></p></div><div id="rfc.section.9.3.p.2"><p>When MKCOL is invoked without a request body, the newly created collection <em class="bcp14">SHOULD</em> have no members.<a class="self" href="#rfc.section.9.3.p.2">¶</a></p></div><div id="rfc.section.9.3.p.3"><p>A
 MKCOL request message may contain a message body. The precise behavior 
of a MKCOL request when the body is present is undefined, but limited to
 creating collections, members of a collection, bodies of members, and 
properties on the collections or members. If the server receives a MKCOL
 request entity type it does not support or understand, it <em class="bcp14">MUST</em>
 respond with a 415 (Unsupported Media Type) status code. If the server 
decides to reject the request based on the presence of an entity or the 
type of an entity, it should use the 415 (Unsupported Media Type) status
 code.<a class="self" href="#rfc.section.9.3.p.3">¶</a></p></div><div id="rfc.section.9.3.p.4"><p>This method is idempotent, but not safe (see <a href="https://tools.ietf.org/html/rfc2616#section-9.1">Section 9.1</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.14"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>). Responses to this method <em class="bcp14">MUST NOT</em> be cached.<a class="self" href="#rfc.section.9.3.p.4">¶</a></p></div><section id="n-mkcol-status-codes"><h4 id="rfc.section.9.3.1"><a href="#rfc.section.9.3.1">9.3.1</a>&nbsp;<a href="#n-mkcol-status-codes">MKCOL Status Codes</a></h4><div id="rfc.section.9.3.1.p.1" class="avoidbreakafter"><p>In addition to the general status codes possible, the following status codes have specific applicability to MKCOL:<a class="self" href="#rfc.section.9.3.1.p.1">¶</a></p></div><div id="rfc.section.9.3.1.p.2"><p>201 (Created) - The collection was created.<a class="self" href="#rfc.section.9.3.1.p.2">¶</a></p></div><div id="rfc.section.9.3.1.p.3"><p>403
 (Forbidden) - This indicates at least one of two conditions: 1) the 
server does not allow the creation of collections at the given location 
in its URL namespace, or 2) the parent collection of the Request-URI 
exists but cannot accept members.<a class="self" href="#rfc.section.9.3.1.p.3">¶</a></p></div><div id="rfc.section.9.3.1.p.4"><p>405 (Method Not Allowed) - MKCOL can only be executed on an unmapped URL.<a class="self" href="#rfc.section.9.3.1.p.4">¶</a></p></div><div id="rfc.section.9.3.1.p.5"><p>409
 (Conflict) - A collection cannot be made at the Request-URI until one 
or more intermediate collections have been created. The server <em class="bcp14">MUST NOT</em> create those intermediate collections automatically.<a class="self" href="#rfc.section.9.3.1.p.5">¶</a></p></div><div id="rfc.section.9.3.1.p.6"><p>415
 (Unsupported Media Type) - The server does not support the request body
 type (although bodies are legal on MKCOL requests, since this 
specification doesn't define any, the server is likely not to support 
any given body type).<a class="self" href="#rfc.section.9.3.1.p.6">¶</a></p></div><div id="rfc.section.9.3.1.p.7"><p>507
 (Insufficient Storage) - The resource does not have sufficient space to
 record the state of the resource after the execution of this method.<a class="self" href="#rfc.section.9.3.1.p.7">¶</a></p></div></section><section id="n-example---mkcol"><h4 id="rfc.section.9.3.2"><a href="#rfc.section.9.3.2">9.3.2</a>&nbsp;<a href="#n-example---mkcol">Example - MKCOL</a></h4><div id="rfc.section.9.3.2.p.1"><p>This example creates a collection called /webdisc/xfiles/ on the server www.example.com.<a class="self" href="#rfc.section.9.3.2.p.1">¶</a></p></div><div id="rfc.figure.u.22"><p>&gt;&gt;Request</p><pre class="text2">  MKCOL /webdisc/xfiles/ HTTP/1.1 
  Host: www.example.com 
</pre></div><div id="rfc.figure.u.23"><p>&gt;&gt;Response</p><pre class="text">  HTTP/1.1 201 Created 
</pre></div></section></section><section id="n-get--head-for-collections"><h3 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a>&nbsp;<a href="#n-get--head-for-collections">GET, HEAD for Collections</a></h3><div id="rfc.section.9.4.p.1"><p>The
 semantics of GET are unchanged when applied to a collection, since GET 
is defined as, "retrieve whatever information (in the form of an entity)
 is identified by the Request-URI" <a href="#RFC2616" id="rfc.xref.RFC2616.15"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.
 GET, when applied to a collection, may return the contents of an 
"index.html" resource, a human-readable view of the contents of the 
collection, or something else altogether. Hence, it is possible that the
 result of a GET on a collection will bear no correlation to the 
membership of the collection.<a class="self" href="#rfc.section.9.4.p.1">¶</a></p></div><div id="rfc.section.9.4.p.2"><p>Similarly,
 since the definition of HEAD is a GET without a response message body, 
the semantics of HEAD are unmodified when applied to collection 
resources.<a class="self" href="#rfc.section.9.4.p.2">¶</a></p></div></section><section id="METHOD_POST"><h3 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a>&nbsp;<a href="#METHOD_POST">POST for Collections</a></h3><div id="rfc.section.9.5.p.1"><p>Since
 by definition the actual function performed by POST is determined by 
the server and often depends on the particular resource, the behavior of
 POST when applied to collections cannot be meaningfully modified 
because it is largely undefined. Thus, the semantics of POST are 
unmodified when applied to a collection.<a class="self" href="#rfc.section.9.5.p.1">¶</a></p></div></section><section id="METHOD_DELETE"><h3 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a>&nbsp;<a href="#METHOD_DELETE">DELETE Requirements</a></h3><div id="rfc.section.9.6.p.1"><p>DELETE is defined in <a href="#RFC2616" id="rfc.xref.RFC2616.16"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="https://tools.ietf.org/html/rfc2616#section-9.7">Section 9.7</a>, to "delete the resource identified by the Request-URI". However, WebDAV changes some DELETE handling requirements.<a class="self" href="#rfc.section.9.6.p.1">¶</a></p></div><div id="rfc.section.9.6.p.2"><p>A server processing a successful DELETE request: <a class="self" href="#rfc.section.9.6.p.2">¶</a></p><ul class="empty"><li><em class="bcp14">MUST</em> destroy locks rooted on the deleted resource</li><li><em class="bcp14">MUST</em> remove the mapping from the Request-URI to any resource.</li></ul><p>
 Thus, after a successful DELETE operation (and in the absence of other 
actions), a subsequent GET/HEAD/PROPFIND request to the target 
Request-URI <em class="bcp14">MUST</em> return 404 (Not Found).</p></div><section id="delete-collections"><h4 id="rfc.section.9.6.1"><a href="#rfc.section.9.6.1">9.6.1</a>&nbsp;<a href="#delete-collections">DELETE for Collections</a></h4><div id="rfc.section.9.6.1.p.1"><p>The DELETE method on a collection <em class="bcp14">MUST</em> act as if a "Depth: infinity" header was used on it. A client <em class="bcp14">MUST NOT</em> submit a Depth header with a DELETE on a collection with any value but infinity.<a class="self" href="#rfc.section.9.6.1.p.1">¶</a></p></div><div id="rfc.section.9.6.1.p.2"><p>DELETE
 instructs that the collection specified in the Request-URI and all 
resources identified by its internal member URLs are to be deleted.<a class="self" href="#rfc.section.9.6.1.p.2">¶</a></p></div><div id="rfc.section.9.6.1.p.3"><p>If any resource identified by a member URL cannot be deleted, then all of the member's ancestors <em class="bcp14">MUST NOT</em> be deleted, so as to maintain URL namespace consistency.<a class="self" href="#rfc.section.9.6.1.p.3">¶</a></p></div><div id="rfc.section.9.6.1.p.4"><p>Any headers included with DELETE <em class="bcp14">MUST</em> be applied in processing every resource to be deleted.<a class="self" href="#rfc.section.9.6.1.p.4">¶</a></p></div><div id="rfc.section.9.6.1.p.5"><p>When the DELETE method has completed processing, it <em class="bcp14">MUST</em> result in a consistent URL namespace.<a class="self" href="#rfc.section.9.6.1.p.5">¶</a></p></div><div id="rfc.section.9.6.1.p.6"><p>If
 an error occurs deleting a member resource (a resource other than the 
resource identified in the Request-URI), then the response can be a 207 
(Multi-Status). Multi-Status is used here to indicate which internal 
resources could NOT be deleted, including an error code, which should 
help the client understand which resources caused the failure. For 
example, the Multi-Status body could include a response with status 423 
(Locked) if an internal resource was locked.<a class="self" href="#rfc.section.9.6.1.p.6">¶</a></p></div><div id="rfc.section.9.6.1.p.7"><p>The server <em class="bcp14">MAY</em> return a 4xx status response, rather than a 207, if the request failed completely.<a class="self" href="#rfc.section.9.6.1.p.7">¶</a></p></div><div id="rfc.section.9.6.1.p.8"><p>424 (Failed Dependency) status codes <em class="bcp14">SHOULD NOT</em>
 be in the 207 (Multi-Status) response for DELETE. They can be safely 
left out because the client will know that the ancestors of a resource 
could not be deleted when the client receives an error for the 
ancestor's progeny. Additionally, 204 (No Content) errors <em class="bcp14">SHOULD NOT</em> be returned in the 207 (Multi-Status). The reason for this prohibition is that 204 (No Content) is the default success code.<a class="self" href="#rfc.section.9.6.1.p.8">¶</a></p></div></section><section id="DELETE-example"><h4 id="rfc.section.9.6.2"><a href="#rfc.section.9.6.2">9.6.2</a>&nbsp;<a href="#DELETE-example">Example - DELETE</a></h4><div id="rfc.figure.u.24"><p>&gt;&gt;Request</p><pre class="text2">  DELETE  /container/ HTTP/1.1 
  Host: www.example.com 
</pre></div><div id="rfc.figure.u.25"><p>&gt;&gt;Response</p><pre class="text">  HTTP/1.1 207 Multi-Status 
  Content-Type: application/xml; charset="utf-8" 
  Content-Length: xxxx 
      
  &lt;?xml version="1.0" encoding="utf-8" ?&gt; 
  &lt;d:multistatus xmlns:d="DAV:"&gt; 
    &lt;d:response&gt; 
      &lt;d:href&gt;http://www.example.com/container/resource3&lt;/d:href&gt; 
      &lt;d:status&gt;HTTP/1.1 423 Locked&lt;/d:status&gt; 
      &lt;d:error&gt;&lt;d:lock-token-submitted/&gt;&lt;/d:error&gt;
    &lt;/d:response&gt; 
  &lt;/d:multistatus&gt; 
</pre></div><div id="rfc.section.9.6.2.p.1"><p>In this example, the 
attempt to delete http://www.example.com/container/resource3 failed 
because it is locked, and no lock token was submitted with the request. 
Consequently, the attempt to delete http://www.example.com/container/ 
also failed. Thus, the client knows that the attempt to delete 
http://www.example.com/container/ must have also failed since the parent
 cannot be deleted unless its child has also been deleted. Even though a
 Depth header has not been included, a depth of infinity is assumed 
because the method is on a collection.<a class="self" href="#rfc.section.9.6.2.p.1">¶</a></p></div></section></section><section id="METHOD_PUT"><h3 id="rfc.section.9.7"><a href="#rfc.section.9.7">9.7</a>&nbsp;<a href="#METHOD_PUT">PUT Requirements</a></h3><section id="put-resources"><h4 id="rfc.section.9.7.1"><a href="#rfc.section.9.7.1">9.7.1</a>&nbsp;<a href="#put-resources">PUT for Non-Collection Resources</a></h4><div id="rfc.section.9.7.1.p.1"><p>A
 PUT performed on an existing resource replaces the GET response entity 
of the resource. Properties defined on the resource may be recomputed 
during PUT processing but are not otherwise affected. For example, if a 
server recognizes the content type of the request body, it may be able 
to automatically extract information that could be profitably exposed as
 properties.<a class="self" href="#rfc.section.9.7.1.p.1">¶</a></p></div><div id="rfc.section.9.7.1.p.2"><p>A PUT that would result in the creation of a resource without an appropriately scoped parent collection <em class="bcp14">MUST</em> fail with a 409 (Conflict).<a class="self" href="#rfc.section.9.7.1.p.2">¶</a></p></div><div id="rfc.section.9.7.1.p.3"><p>A
 PUT request allows a client to indicate what media type an entity body 
has, and whether it should change if overwritten. Thus, a client <em class="bcp14">SHOULD</em>
 provide a Content-Type for a new resource if any is known. If the 
client does not provide a Content-Type for a new resource, the server <em class="bcp14">MAY</em> create a resource with no Content-Type assigned, or it <em class="bcp14">MAY</em> attempt to assign a Content-Type.<a class="self" href="#rfc.section.9.7.1.p.3">¶</a></p></div><div id="rfc.section.9.7.1.p.4"><p>Note
 that although a recipient ought generally to treat metadata supplied 
with an HTTP request as authoritative, in practice there's no guarantee 
that a server will accept client-supplied metadata (e.g., any request 
header beginning with "Content-"). Many servers do not allow configuring
 the Content-Type on a per-resource basis in the first place. Thus, 
clients can't always rely on the ability to directly influence the 
content type by including a Content-Type request header.<a class="self" href="#rfc.section.9.7.1.p.4">¶</a></p></div></section><section id="n-put-for-collections"><h4 id="rfc.section.9.7.2"><a href="#rfc.section.9.7.2">9.7.2</a>&nbsp;<a href="#n-put-for-collections">PUT for Collections</a></h4><div id="rfc.section.9.7.2.p.1"><p>This
 specification does not define the behavior of the PUT method for 
existing collections. A PUT request to an existing collection <em class="bcp14">MAY</em> be treated as an error (405 Method Not Allowed).<a class="self" href="#rfc.section.9.7.2.p.1">¶</a></p></div><div id="rfc.section.9.7.2.p.2"><p>The MKCOL method is defined to create collections.<a class="self" href="#rfc.section.9.7.2.p.2">¶</a></p></div></section></section><section id="METHOD_COPY"><h3 id="rfc.section.9.8"><a href="#rfc.section.9.8">9.8</a>&nbsp;<a href="#METHOD_COPY">COPY Method</a></h3><div id="rfc.section.9.8.p.1"><p>The
 COPY method creates a duplicate of the source resource identified by 
the Request-URI, in the destination resource identified by the URI in 
the Destination header. The Destination header <em class="bcp14">MUST</em> be present. The exact behavior of the COPY method depends on the type of the source resource.<a class="self" href="#rfc.section.9.8.p.1">¶</a></p></div><div id="rfc.section.9.8.p.2"><p>All WebDAV-compliant resources <em class="bcp14">MUST</em>
 support the COPY method. However, support for the COPY method does not 
guarantee the ability to copy a resource. For example, separate programs
 may control resources on the same server. As a result, it may not be 
possible to copy a resource to a location that appears to be on the same
 server.<a class="self" href="#rfc.section.9.8.p.2">¶</a></p></div><div id="rfc.section.9.8.p.3"><p>This method is idempotent, but not safe (see <a href="https://tools.ietf.org/html/rfc2616#section-9.1">Section 9.1</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.17"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>). Responses to this method <em class="bcp14">MUST NOT</em> be cached.<a class="self" href="#rfc.section.9.8.p.3">¶</a></p></div><section id="n-copy-for-non-collection-resources"><h4 id="rfc.section.9.8.1"><a href="#rfc.section.9.8.1">9.8.1</a>&nbsp;<a href="#n-copy-for-non-collection-resources">COPY for Non-collection Resources</a></h4><div id="rfc.section.9.8.1.p.1"><p>When
 the source resource is not a collection, the result of the COPY method 
is the creation of a new resource at the destination whose state and 
behavior match that of the source resource as closely as possible. Since
 the environment at the destination may be different than at the source 
due to factors outside the scope of control of the server, such as the 
absence of resources required for correct operation, it may not be 
possible to completely duplicate the behavior of the resource at the 
destination. Subsequent alterations to the destination resource will not
 modify the source resource. Subsequent alterations to the source 
resource will not modify the destination resource.<a class="self" href="#rfc.section.9.8.1.p.1">¶</a></p></div></section><section id="copy.for.properties"><h4 id="rfc.section.9.8.2"><a href="#rfc.section.9.8.2">9.8.2</a>&nbsp;<a href="#copy.for.properties">COPY for Properties</a></h4><div id="rfc.section.9.8.2.p.1"><p>After a successful COPY invocation, all dead properties on the source resource <em class="bcp14">SHOULD</em> be duplicated on the destination resource. Live properties described in this document <em class="bcp14">SHOULD</em>
 be duplicated as identically behaving live properties at the 
destination resource, but not necessarily with the same values. Servers <em class="bcp14">SHOULD NOT</em>
 convert live properties into dead properties on the destination 
resource, because clients may then draw incorrect conclusions about the 
state or functionality of a resource. Note that some live properties are
 defined such that the absence of the property has a specific meaning 
(e.g., a flag with one meaning if present, and the opposite if absent), 
and in these cases, a successful COPY might result in the property being
 reported as "Not Found" in subsequent requests.<a class="self" href="#rfc.section.9.8.2.p.1">¶</a></p></div><div id="rfc.section.9.8.2.p.2"><p>When
 the destination is an unmapped URL, a COPY operation creates a new 
resource much like a PUT operation does. Live properties that are 
related to resource creation (such as DAV:creationdate) should have 
their values set accordingly.<a class="self" href="#rfc.section.9.8.2.p.2">¶</a></p></div></section><section id="copy.for.collections"><h4 id="rfc.section.9.8.3"><a href="#rfc.section.9.8.3">9.8.3</a>&nbsp;<a href="#copy.for.collections">COPY for Collections</a></h4><div id="rfc.section.9.8.3.p.1"><p>The COPY method on a collection without a Depth header <em class="bcp14">MUST</em>
 act as if a Depth header with value "infinity" was included. A client 
may submit a Depth header on a COPY on a collection with a value of "0" 
or "infinity". Servers <em class="bcp14">MUST</em> support the "0" and "infinity" Depth header behaviors on WebDAV-compliant resources.<a class="self" href="#rfc.section.9.8.3.p.1">¶</a></p></div><div id="rfc.section.9.8.3.p.2"><p>An
 infinite-depth COPY instructs that the collection resource identified 
by the Request-URI is to be copied to the location identified by the URI
 in the Destination header, and all its internal member resources are to
 be copied to a location relative to it, recursively through all levels 
of the collection hierarchy. Note that an infinite-depth COPY of /A/ 
into /A/B/ could lead to infinite recursion if not handled correctly.<a class="self" href="#rfc.section.9.8.3.p.2">¶</a></p></div><div id="rfc.section.9.8.3.p.3"><p>A
 COPY of "Depth: 0" only instructs that the collection and its 
properties, but not resources identified by its internal member URLs, 
are to be copied.<a class="self" href="#rfc.section.9.8.3.p.3">¶</a></p></div><div id="rfc.section.9.8.3.p.4"><p>Any headers included with a COPY <em class="bcp14">MUST</em> be applied in processing every resource to be copied with the exception of the Destination header.<a class="self" href="#rfc.section.9.8.3.p.4">¶</a></p></div><div id="rfc.section.9.8.3.p.5"><p>The
 Destination header only specifies the destination URI for the 
Request-URI. When applied to members of the collection identified by the
 Request-URI, the value of Destination is to be modified to reflect the 
current location in the hierarchy. So, if the Request-URI is /a/ with 
Host header value http://example.com/ and the Destination is 
http://example.com/b/, then when http://example.com/a/c/d is processed, 
it must use a Destination of http://example.com/b/c/d.<a class="self" href="#rfc.section.9.8.3.p.5">¶</a></p></div><div id="rfc.section.9.8.3.p.6"><p>When the COPY method has completed processing, it <em class="bcp14">MUST</em> have created a consistent URL namespace at the destination (see <a href="#http.url.namespace.model" title="HTTP URL Namespace Model">Section&nbsp;5.1</a> for the definition of namespace consistency). However, if an error occurs while copying an internal collection, the server <em class="bcp14">MUST NOT</em>
 copy any resources identified by members of this collection (i.e., the 
server must skip this subtree), as this would create an inconsistent 
namespace. After detecting an error, the COPY operation <em class="bcp14">SHOULD</em>
 try to finish as much of the original copy operation as possible (i.e.,
 the server should still attempt to copy other subtrees and their 
members that are not descendants of an error-causing collection).<a class="self" href="#rfc.section.9.8.3.p.6">¶</a></p></div><div id="rfc.section.9.8.3.p.7"><p>So,
 for example, if an infinite-depth copy operation is performed on 
collection /a/, which contains collections /a/b/ and /a/c/, and an error
 occurs copying /a/b/, an attempt should still be made to copy /a/c/. 
Similarly, after encountering an error copying a non-collection resource
 as part of an infinite-depth copy, the server <em class="bcp14">SHOULD</em> try to finish as much of the original copy operation as possible.<a class="self" href="#rfc.section.9.8.3.p.7">¶</a></p></div><div id="rfc.section.9.8.3.p.8"><p>If
 an error in executing the COPY method occurs with a resource other than
 the resource identified in the Request-URI, then the response <em class="bcp14">MUST</em> be a 207 (Multi-Status), and the URL of the resource causing the failure <em class="bcp14">MUST</em> appear with the specific error.<a class="self" href="#rfc.section.9.8.3.p.8">¶</a></p></div><div id="rfc.section.9.8.3.p.9"><p>The 424 (Failed Dependency) status code <em class="bcp14">SHOULD NOT</em>
 be returned in the 207 (Multi-Status) response from a COPY method. 
These responses can be safely omitted because the client will know that 
the progeny of a resource could not be copied when the client receives 
an error for the parent. Additionally, 201 (Created)/204 (No Content) 
status codes <em class="bcp14">SHOULD NOT</em> be returned as values in 
207 (Multi-Status) responses from COPY methods. They, too, can be safely
 omitted because they are the default success codes.<a class="self" href="#rfc.section.9.8.3.p.9">¶</a></p></div></section><section id="n-copy-and-overwriting-destination-resources"><h4 id="rfc.section.9.8.4"><a href="#rfc.section.9.8.4">9.8.4</a>&nbsp;<a href="#n-copy-and-overwriting-destination-resources">COPY and Overwriting Destination Resources</a></h4><div id="rfc.section.9.8.4.p.1"><p>If a COPY request has an Overwrite header with a value of "F", and a resource exists at the Destination URL, the server <em class="bcp14">MUST</em> fail the request.<a class="self" href="#rfc.section.9.8.4.p.1">¶</a></p></div><div id="rfc.section.9.8.4.p.2"><p>When a server executes a COPY request and overwrites a destination resource, the exact behavior <em class="bcp14">MAY</em> depend on many factors, including WebDAV extension capabilities (see particularly <a href="#RFC3253" id="rfc.xref.RFC3253.5"><cite title="Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)">[RFC3253]</cite></a>).
 For example, when an ordinary resource is overwritten, the server could
 delete the target resource before doing the copy, or could do an 
in-place overwrite to preserve live properties.<a class="self" href="#rfc.section.9.8.4.p.2">¶</a></p></div><div id="rfc.section.9.8.4.p.3"><p>When a collection is overwritten, the membership of the destination collection after the successful COPY request <em class="bcp14">MUST</em>
 be the same membership as the source collection immediately before the 
COPY. Thus, merging the membership of the source and destination 
collections together in the destination is not a compliant behavior.<a class="self" href="#rfc.section.9.8.4.p.3">¶</a></p></div><div id="rfc.section.9.8.4.p.4"><p>In
 general, if clients require the state of the destination URL to be 
wiped out prior to a COPY (e.g., to force live properties to be reset), 
then the client could send a DELETE to the destination before the COPY 
request to ensure this reset.<a class="self" href="#rfc.section.9.8.4.p.4">¶</a></p></div></section><section id="n-status-codes_1"><h4 id="rfc.section.9.8.5"><a href="#rfc.section.9.8.5">9.8.5</a>&nbsp;<a href="#n-status-codes_1">Status Codes</a></h4><div id="rfc.section.9.8.5.p.1" class="avoidbreakafter"><p>In addition to the general status codes possible, the following status codes have specific applicability to COPY:<a class="self" href="#rfc.section.9.8.5.p.1">¶</a></p></div><div id="rfc.section.9.8.5.p.2"><p>201 (Created) - The source resource was successfully copied. The COPY operation resulted in the creation of a new resource.<a class="self" href="#rfc.section.9.8.5.p.2">¶</a></p></div><div id="rfc.section.9.8.5.p.3"><p>204 (No Content) - The source resource was successfully copied to a preexisting destination resource.<a class="self" href="#rfc.section.9.8.5.p.3">¶</a></p></div><div id="rfc.section.9.8.5.p.4"><p>207
 (Multi-Status) - Multiple resources were to be affected by the COPY, 
but errors on some of them prevented the operation from taking place. 
Specific error messages, together with the most appropriate of the 
source and destination URLs, appear in the body of the multi-status 
response. For example, if a destination resource was locked and could 
not be overwritten, then the destination resource URL appears with the 
423 (Locked) status.<a class="self" href="#rfc.section.9.8.5.p.4">¶</a></p></div><div id="rfc.section.9.8.5.p.5"><p>403
 (Forbidden) - The operation is forbidden. A special case for COPY could
 be that the source and destination resources are the same resource.<a class="self" href="#rfc.section.9.8.5.p.5">¶</a></p></div><div id="rfc.section.9.8.5.p.6"><p>409
 (Conflict) - A resource cannot be created at the destination until one 
or more intermediate collections have been created. The server <em class="bcp14">MUST NOT</em> create those intermediate collections automatically.<a class="self" href="#rfc.section.9.8.5.p.6">¶</a></p></div><div id="rfc.section.9.8.5.p.7"><p>412
 (Precondition Failed) - A precondition header check failed, e.g., the 
Overwrite header is "F" and the destination URL is already mapped to a 
resource.<a class="self" href="#rfc.section.9.8.5.p.7">¶</a></p></div><div id="rfc.section.9.8.5.p.8"><p>423 (Locked) - The destination resource, or resource within the destination collection, was locked. This response <em class="bcp14">SHOULD</em> contain the 'lock-token-submitted' precondition element.<a class="self" href="#rfc.section.9.8.5.p.8">¶</a></p></div><div id="rfc.section.9.8.5.p.9"><p>502
 (Bad Gateway) - This may occur when the destination is on another 
server, repository, or URL namespace. Either the source namespace does 
not support copying to the destination namespace, or the destination 
namespace refuses to accept the resource. The client may wish to try 
GET/PUT and PROPFIND/PROPPATCH instead.<a class="self" href="#rfc.section.9.8.5.p.9">¶</a></p></div><div id="rfc.section.9.8.5.p.10"><p>507
 (Insufficient Storage) - The destination resource does not have 
sufficient space to record the state of the resource after the execution
 of this method.<a class="self" href="#rfc.section.9.8.5.p.10">¶</a></p></div></section><section id="n-example---copy-with-overwrite"><h4 id="rfc.section.9.8.6"><a href="#rfc.section.9.8.6">9.8.6</a>&nbsp;<a href="#n-example---copy-with-overwrite">Example - COPY with Overwrite</a></h4><div id="rfc.section.9.8.6.p.1"><p>This
 example shows resource http://www.example.com/~fielding/index.html 
being copied to the location 
http://www.example.com/users/f/fielding/index.html. The 204 (No Content)
 status code indicates that the existing resource at the destination was
 overwritten.<a class="self" href="#rfc.section.9.8.6.p.1">¶</a></p></div><div id="rfc.figure.u.26"><p>&gt;&gt;Request</p><pre class="text2">  COPY /~fielding/index.html HTTP/1.1 
  Host: www.example.com 
  Destination: http://www.example.com/users/f/fielding/index.html 
</pre></div><div id="rfc.figure.u.27"><p>&gt;&gt;Response</p><pre class="text">  HTTP/1.1 204 No Content 
</pre></div></section><section id="n-example---copy-with-no-overwrite"><h4 id="rfc.section.9.8.7"><a href="#rfc.section.9.8.7">9.8.7</a>&nbsp;<a href="#n-example---copy-with-no-overwrite">Example - COPY with No Overwrite</a></h4><div id="rfc.section.9.8.7.p.1"><p>The
 following example shows the same copy operation being performed, but 
with the Overwrite header set to "F." A response of 412 (Precondition 
Failed) is returned because the destination URL is already mapped to a 
resource.<a class="self" href="#rfc.section.9.8.7.p.1">¶</a></p></div><div id="rfc.figure.u.28"><p>&gt;&gt;Request</p><pre class="text2">  COPY /~fielding/index.html HTTP/1.1 
  Host: www.example.com 
  Destination: http://www.example.com/users/f/fielding/index.html 
  Overwrite: F 
</pre></div><div id="rfc.figure.u.29"><p>&gt;&gt;Response</p><pre class="text">  HTTP/1.1 412 Precondition Failed 
</pre></div></section><section id="n-example---copy-of-a-collection"><h4 id="rfc.section.9.8.8"><a href="#rfc.section.9.8.8">9.8.8</a>&nbsp;<a href="#n-example---copy-of-a-collection">Example - COPY of a Collection</a></h4><div id="rfc.figure.u.30"><p>&gt;&gt;Request</p><pre class="text2">  COPY /container/ HTTP/1.1 
  Host: www.example.com 
  Destination: http://www.example.com/othercontainer/ 
  Depth: infinity 
</pre></div><div id="rfc.figure.u.31"><p>&gt;&gt;Response</p><pre class="text">  HTTP/1.1 207 Multi-Status 
  Content-Type: application/xml; charset="utf-8" 
  Content-Length: xxxx 
  
  &lt;?xml version="1.0" encoding="utf-8" ?&gt; 
  
  &lt;d:multistatus xmlns:d="DAV:"&gt; 
    &lt;d:response&gt; 
      &lt;d:href&gt;http://www.example.com/othercontainer/R2/&lt;/d:href&gt; 
      &lt;d:status&gt;HTTP/1.1 423 Locked&lt;/d:status&gt; 
      &lt;d:error&gt;&lt;d:lock-token-submitted/&gt;&lt;/d:error&gt;
    &lt;/d:response&gt; 
  &lt;/d:multistatus&gt; 
</pre></div><div id="rfc.section.9.8.8.p.1"><p>The Depth header is 
unnecessary as the default behavior of COPY on a collection is to act as
 if a "Depth: infinity" header had been submitted. In this example, most
 of the resources, along with the collection, were copied successfully. 
However, the collection R2 failed because the destination R2 is locked. 
Because there was an error copying R2, none of R2's members were copied.
 However, no errors were listed for those members due to the error 
minimization rules.<a class="self" href="#rfc.section.9.8.8.p.1">¶</a></p></div></section></section><section id="METHOD_MOVE"><h3 id="rfc.section.9.9"><a href="#rfc.section.9.9">9.9</a>&nbsp;<a href="#METHOD_MOVE">MOVE Method</a></h3><div id="rfc.section.9.9.p.1"><p>The
 MOVE operation on a non-collection resource is the logical equivalent 
of a copy (COPY), followed by consistency maintenance processing, 
followed by a delete of the source, where all three actions are 
performed in a single operation. The consistency maintenance step allows
 the server to perform updates caused by the move, such as updating all 
URLs, other than the Request-URI that identifies the source resource, to
 point to the new destination resource.<a class="self" href="#rfc.section.9.9.p.1">¶</a></p></div><div id="rfc.section.9.9.p.2"><p>The Destination header <em class="bcp14">MUST</em> be present on all MOVE methods and <em class="bcp14">MUST</em> follow all COPY requirements for the COPY part of the MOVE method. All WebDAV-compliant resources <em class="bcp14">MUST</em> support the MOVE method.<a class="self" href="#rfc.section.9.9.p.2">¶</a></p></div><div id="rfc.section.9.9.p.3"><p>Support
 for the MOVE method does not guarantee the ability to move a resource 
to a particular destination. For example, separate programs may actually
 control different sets of resources on the same server. Therefore, it 
may not be possible to move a resource within a namespace that appears 
to belong to the same server.<a class="self" href="#rfc.section.9.9.p.3">¶</a></p></div><div id="rfc.section.9.9.p.4"><p>If
 a resource exists at the destination, the destination resource will be 
deleted as a side-effect of the MOVE operation, subject to the 
restrictions of the Overwrite header.<a class="self" href="#rfc.section.9.9.p.4">¶</a></p></div><div id="rfc.section.9.9.p.5"><p>This method is idempotent, but not safe (see <a href="https://tools.ietf.org/html/rfc2616#section-9.1">Section 9.1</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.18"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>). Responses to this method <em class="bcp14">MUST NOT</em> be cached.<a class="self" href="#rfc.section.9.9.p.5">¶</a></p></div><section id="move-properties"><h4 id="rfc.section.9.9.1"><a href="#rfc.section.9.9.1">9.9.1</a>&nbsp;<a href="#move-properties">MOVE for Properties</a></h4><div id="rfc.section.9.9.1.p.1"><p>Live properties described in this document <em class="bcp14">SHOULD</em>
 be moved along with the resource, such that the resource has 
identically behaving live properties at the destination resource, but 
not necessarily with the same values. Note that some live properties are
 defined such that the absence of the property has a specific meaning 
(e.g., a flag with one meaning if present, and the opposite if absent), 
and in these cases, a successful MOVE might result in the property being
 reported as "Not Found" in subsequent requests. If the live properties 
will not work the same way at the destination, the server <em class="bcp14">MAY</em> fail the request.<a class="self" href="#rfc.section.9.9.1.p.1">¶</a></p></div><div id="rfc.section.9.9.1.p.2"><p>MOVE
 is frequently used by clients to rename a file without changing its 
parent collection, so it's not appropriate to reset all live properties 
that are set at resource creation. For example, the DAV:creationdate 
property value <em class="bcp14">SHOULD</em> remain the same after a MOVE.<a class="self" href="#rfc.section.9.9.1.p.2">¶</a></p></div><div id="rfc.section.9.9.1.p.3"><p>Dead properties <em class="bcp14">MUST</em> be moved along with the resource.<a class="self" href="#rfc.section.9.9.1.p.3">¶</a></p></div></section><section id="move-collections"><h4 id="rfc.section.9.9.2"><a href="#rfc.section.9.9.2">9.9.2</a>&nbsp;<a href="#move-collections">MOVE for Collections</a></h4><div id="rfc.section.9.9.2.p.1"><p>A
 MOVE with "Depth: infinity" instructs that the collection identified by
 the Request-URI be moved to the address specified in the Destination 
header, and all resources identified by its internal member URLs are to 
be moved to locations relative to it, recursively through all levels of 
the collection hierarchy.<a class="self" href="#rfc.section.9.9.2.p.1">¶</a></p></div><div id="rfc.section.9.9.2.p.2"><p>The MOVE method on a collection <em class="bcp14">MUST</em> act as if a "Depth: infinity" header was used on it. A client <em class="bcp14">MUST NOT</em> submit a Depth header on a MOVE on a collection with any value but "infinity".<a class="self" href="#rfc.section.9.9.2.p.2">¶</a></p></div><div id="rfc.section.9.9.2.p.3"><p>Any headers included with MOVE <em class="bcp14">MUST</em>
 be applied in processing every resource to be moved with the exception 
of the Destination header. The behavior of the Destination header is the
 same as given for COPY on collections.<a class="self" href="#rfc.section.9.9.2.p.3">¶</a></p></div><div id="rfc.section.9.9.2.p.4"><p>When the MOVE method has completed processing, it <em class="bcp14">MUST</em> have created a consistent URL namespace at both the source and destination (see <a href="#http.url.namespace.model" title="HTTP URL Namespace Model">Section&nbsp;5.1</a> for the definition of namespace consistency). However, if an error occurs while moving an internal collection, the server <em class="bcp14">MUST NOT</em>
 move any resources identified by members of the failed collection 
(i.e., the server must skip the error-causing subtree), as this would 
create an inconsistent namespace. In this case, after detecting the 
error, the move operation <em class="bcp14">SHOULD</em> try to finish as
 much of the original move as possible (i.e., the server should still 
attempt to move other subtrees and the resources identified by their 
members that are not descendants of an error-causing collection). So, 
for example, if an infinite-depth move is performed on collection /a/, 
which contains collections /a/b/ and /a/c/, and an error occurs moving 
/a/b/, an attempt should still be made to try moving /a/c/. Similarly, 
after encountering an error moving a non-collection resource as part of 
an infinite-depth move, the server <em class="bcp14">SHOULD</em> try to finish as much of the original move operation as possible.<a class="self" href="#rfc.section.9.9.2.p.4">¶</a></p></div><div id="rfc.section.9.9.2.p.5"><p>If an error occurs with a resource other than the resource identified in the Request-URI, then the response <em class="bcp14">MUST</em> be a 207 (Multi-Status), and the errored resource's URL <em class="bcp14">MUST</em> appear with the specific error.<a class="self" href="#rfc.section.9.9.2.p.5">¶</a></p></div><div id="rfc.section.9.9.2.p.6"><p>The 424 (Failed Dependency) status code <em class="bcp14">SHOULD NOT</em>
 be returned in the 207 (Multi-Status) response from a MOVE method. 
These errors can be safely omitted because the client will know that the
 progeny of a resource could not be moved when the client receives an 
error for the parent. Additionally, 201 (Created)/204 (No Content) 
responses <em class="bcp14">SHOULD NOT</em> be returned as values in 207
 (Multi-Status) responses from a MOVE. These responses can be safely 
omitted because they are the default success codes.<a class="self" href="#rfc.section.9.9.2.p.6">¶</a></p></div></section><section id="n-move-and-the-overwrite-header"><h4 id="rfc.section.9.9.3"><a href="#rfc.section.9.9.3">9.9.3</a>&nbsp;<a href="#n-move-and-the-overwrite-header">MOVE and the Overwrite Header</a></h4><div id="rfc.section.9.9.3.p.1"><p>If a resource exists at the destination and the Overwrite header is "T", then prior to performing the move, the server <em class="bcp14">MUST</em>
 perform a DELETE with "Depth: infinity" on the destination resource. If
 the Overwrite header is set to "F", then the operation will fail.<a class="self" href="#rfc.section.9.9.3.p.1">¶</a></p></div></section><section id="n-status-codes_2"><h4 id="rfc.section.9.9.4"><a href="#rfc.section.9.9.4">9.9.4</a>&nbsp;<a href="#n-status-codes_2">Status Codes</a></h4><div id="rfc.section.9.9.4.p.1" class="avoidbreakafter"><p>In addition to the general status codes possible, the following status codes have specific applicability to MOVE:<a class="self" href="#rfc.section.9.9.4.p.1">¶</a></p></div><div id="rfc.section.9.9.4.p.2"><p>201 (Created) - The source resource was successfully moved, and a new URL mapping was created at the destination.<a class="self" href="#rfc.section.9.9.4.p.2">¶</a></p></div><div id="rfc.section.9.9.4.p.3"><p>204 (No Content) - The source resource was successfully moved to a URL that was already mapped.<a class="self" href="#rfc.section.9.9.4.p.3">¶</a></p></div><div id="rfc.section.9.9.4.p.4"><p>207
 (Multi-Status) - Multiple resources were to be affected by the MOVE, 
but errors on some of them prevented the operation from taking place. 
Specific error messages, together with the most appropriate of the 
source and destination URLs, appear in the body of the multi-status 
response. For example, if a source resource was locked and could not be 
moved, then the source resource URL appears with the 423 (Locked) 
status.<a class="self" href="#rfc.section.9.9.4.p.4">¶</a></p></div><div id="rfc.section.9.9.4.p.5"><p>403
 (Forbidden) - Among many possible reasons for forbidding a MOVE 
operation, this status code is recommended for use when the source and 
destination resources are the same.<a class="self" href="#rfc.section.9.9.4.p.5">¶</a></p></div><div id="rfc.section.9.9.4.p.6"><p>409
 (Conflict) - A resource cannot be created at the destination until one 
or more intermediate collections have been created. The server <em class="bcp14">MUST NOT</em>
 create those intermediate collections automatically. Or, the server was
 unable to preserve the behavior of the live properties and still move 
the resource to the destination (see 'preserved-live-properties' 
postcondition).<a class="self" href="#rfc.section.9.9.4.p.6">¶</a></p></div><div id="rfc.section.9.9.4.p.7"><p>412
 (Precondition Failed) - A condition header failed. Specific to MOVE, 
this could mean that the Overwrite header is "F" and the destination URL
 is already mapped to a resource.<a class="self" href="#rfc.section.9.9.4.p.7">¶</a></p></div><div id="rfc.section.9.9.4.p.8"><p>423
 (Locked) - The source or the destination resource, the source or 
destination resource parent, or some resource within the source or 
destination collection, was locked. This response <em class="bcp14">SHOULD</em> contain the 'lock-token-submitted' precondition element.<a class="self" href="#rfc.section.9.9.4.p.8">¶</a></p></div><div id="rfc.section.9.9.4.p.9"><p>502
 (Bad Gateway) - This may occur when the destination is on another 
server and the destination server refuses to accept the resource. This 
could also occur when the destination is on another sub-section of the 
same server namespace.<a class="self" href="#rfc.section.9.9.4.p.9">¶</a></p></div></section><section id="n-example---move-of-a-non-collection"><h4 id="rfc.section.9.9.5"><a href="#rfc.section.9.9.5">9.9.5</a>&nbsp;<a href="#n-example---move-of-a-non-collection">Example - MOVE of a Non-Collection</a></h4><div id="rfc.section.9.9.5.p.1"><p>This
 example shows resource http://www.example.com/~fielding/index.html 
being moved to the location 
http://www.example.com/users/f/fielding/index.html. The contents of the 
destination resource would have been overwritten if the destination URL 
was already mapped to a resource. In this case, since there was nothing 
at the destination resource, the response code is 201 (Created).<a class="self" href="#rfc.section.9.9.5.p.1">¶</a></p></div><div id="rfc.figure.u.32"><p>&gt;&gt;Request</p><pre class="text2">  MOVE /~fielding/index.html HTTP/1.1 
  Host: www.example.com 
  Destination: http://www.example/users/f/fielding/index.html 
</pre></div><div id="rfc.figure.u.33"><p>&gt;&gt;Response</p><pre class="text">  HTTP/1.1 201 Created 
  Location: http://www.example.com/users/f/fielding/index.html 
</pre></div></section><section id="n-example---move-of-a-collection"><h4 id="rfc.section.9.9.6"><a href="#rfc.section.9.9.6">9.9.6</a>&nbsp;<a href="#n-example---move-of-a-collection">Example - MOVE of a Collection</a></h4><div id="rfc.figure.u.34"><p>&gt;&gt;Request</p><pre class="text2">  MOVE /container/ HTTP/1.1 
  Host: www.example.com 
  Destination: http://www.example.com/othercontainer/ 
  Overwrite: F 
  If: (&lt;urn:uuid:fe184f2e-6eec-41d0-c765-01adc56e6bb4&gt;) 
     (&lt;urn:uuid:e454f3f3-acdc-452a-56c7-00a5c91e4b77&gt;) 
</pre></div><div id="rfc.figure.u.35"><p>&gt;&gt;Response</p><pre class="text">  HTTP/1.1 207 Multi-Status 
  Content-Type: application/xml; charset="utf-8" 
  Content-Length: xxxx 
  
  &lt;?xml version="1.0" encoding="utf-8" ?&gt; 
  &lt;d:multistatus xmlns:d='DAV:'&gt; 
    &lt;d:response&gt; 
      &lt;d:href&gt;http://www.example.com/othercontainer/C2/&lt;/d:href&gt; 
      &lt;d:status&gt;HTTP/1.1 423 Locked&lt;/d:status&gt; 
      &lt;d:error&gt;&lt;d:lock-token-submitted/&gt;&lt;/d:error&gt;
    &lt;/d:response&gt; 
  &lt;/d:multistatus&gt; 
</pre><p>In this example, the client has submitted a number of lock 
tokens with the request. A lock token will need to be submitted for 
every resource, both source and destination, anywhere in the scope of 
the method, that is locked. In this case, the proper lock token was not 
submitted for the destination http://www.example.com/othercontainer/C2/.
 This means that the resource /container/C2/ could not be moved. Because
 there was an error moving /container/C2/, none of /container/C2's 
members were moved. However, no errors were listed for those members due
 to the error minimization rules. User agent authentication has 
previously occurred via a mechanism outside the scope of the HTTP 
protocol, in an underlying transport layer.</p></div></section></section><section id="METHOD_LOCK"><h3 id="rfc.section.9.10"><a href="#rfc.section.9.10">9.10</a>&nbsp;<a href="#METHOD_LOCK">LOCK Method</a></h3><div id="rfc.section.9.10.p.1"><p>The
 following sections describe the LOCK method, which is used to take out a
 lock of any access type and to refresh an existing lock. These sections
 on the LOCK method describe only those semantics that are specific to 
the LOCK method and are independent of the access type of the lock being
 requested.<a class="self" href="#rfc.section.9.10.p.1">¶</a></p></div><div id="rfc.section.9.10.p.2"><p>Any resource that supports the LOCK method <em class="bcp14">MUST</em>, at minimum, support the XML request and response formats defined herein.<a class="self" href="#rfc.section.9.10.p.2">¶</a></p></div><div id="rfc.section.9.10.p.3"><p>This method is neither idempotent nor safe (see <a href="https://tools.ietf.org/html/rfc2616#section-9.1">Section 9.1</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.19"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>). Responses to this method <em class="bcp14">MUST NOT</em> be cached.<a class="self" href="#rfc.section.9.10.p.3">¶</a></p></div><section id="n-creating-a-lock-on-an-existing-resource"><h4 id="rfc.section.9.10.1"><a href="#rfc.section.9.10.1">9.10.1</a>&nbsp;<a href="#n-creating-a-lock-on-an-existing-resource">Creating a Lock on an Existing Resource</a></h4><div id="rfc.section.9.10.1.p.1"><p>A
 LOCK request to an existing resource will create a lock on the resource
 identified by the Request-URI, provided the resource is not already 
locked with a conflicting lock. The resource identified in the 
Request-URI becomes the root of the lock. LOCK method requests to create
 a new lock <em class="bcp14">MUST</em> have an XML request body. The server <em class="bcp14">MUST</em> preserve the information provided by the client in the 'owner' element in the LOCK request. The LOCK request <em class="bcp14">MAY</em> have a Timeout header.<a class="self" href="#rfc.section.9.10.1.p.1">¶</a></p></div><div id="rfc.section.9.10.1.p.2" class="avoidbreakafter"><p>When a new lock is created, the LOCK response:<a class="self" href="#rfc.section.9.10.1.p.2">¶</a></p></div><div id="rfc.section.9.10.1.p.3"><ul><li><em class="bcp14">MUST</em> contain a body with the value of the DAV:lockdiscovery property in a prop XML element. This <em class="bcp14">MUST</em> contain the full information about the lock just granted, while information about other (shared) locks is <em class="bcp14">OPTIONAL</em>.</li><li><em class="bcp14">MUST</em> include the Lock-Token response header with the token associated with the new lock.</li></ul></div></section><section id="refreshing-locks"><h4 id="rfc.section.9.10.2"><a href="#rfc.section.9.10.2">9.10.2</a>&nbsp;<a href="#refreshing-locks">Refreshing Locks</a></h4><div id="rfc.section.9.10.2.p.1"><p>A lock is refreshed by sending a LOCK request to the URL of a resource within the scope of the lock. This request <em class="bcp14">MUST NOT</em> have a body and it <em class="bcp14">MUST</em>
 specify which lock to refresh by using the 'If' header with a single 
lock token (only one lock may be refreshed at a time). The request <em class="bcp14">MAY</em> contain a Timeout header, which a server <em class="bcp14">MAY</em> accept to change the duration remaining on the lock to the new value. A server <em class="bcp14">MUST</em> ignore the Depth header on a LOCK refresh.<a class="self" href="#rfc.section.9.10.2.p.1">¶</a></p></div><div id="rfc.section.9.10.2.p.2"><p>If
 the resource has other (shared) locks, those locks are unaffected by a 
lock refresh. Additionally, those locks do not prevent the named lock 
from being refreshed.<a class="self" href="#rfc.section.9.10.2.p.2">¶</a></p></div><div id="rfc.section.9.10.2.p.3"><p>The Lock-Token header is not returned in the response for a successful refresh LOCK request, but the LOCK response body <em class="bcp14">MUST</em> contain the new value for the DAV:lockdiscovery property.<a class="self" href="#rfc.section.9.10.2.p.3">¶</a></p></div></section><section id="n-depth-and-locking"><h4 id="rfc.section.9.10.3"><a href="#rfc.section.9.10.3">9.10.3</a>&nbsp;<a href="#n-depth-and-locking">Depth and Locking</a></h4><div id="rfc.section.9.10.3.p.1"><p>The Depth header may be used with the LOCK method. Values other than 0 or infinity <em class="bcp14">MUST NOT</em> be used with the Depth header on a LOCK method. All resources that support the LOCK method <em class="bcp14">MUST</em> support the Depth header.<a class="self" href="#rfc.section.9.10.3.p.1">¶</a></p></div><div id="rfc.section.9.10.3.p.2"><p>A Depth header of value 0 means to just lock the resource specified by the Request-URI.<a class="self" href="#rfc.section.9.10.3.p.2">¶</a></p></div><div id="rfc.section.9.10.3.p.3"><p>If
 the Depth header is set to infinity, then the resource specified in the
 Request-URI along with all its members, all the way down the hierarchy,
 are to be locked. A successful result <em class="bcp14">MUST</em> 
return a single lock token. Similarly, if an UNLOCK is successfully 
executed on this token, all associated resources are unlocked. Hence, 
partial success is not an option for LOCK or UNLOCK. Either the entire 
hierarchy is locked or no resources are locked.<a class="self" href="#rfc.section.9.10.3.p.3">¶</a></p></div><div id="rfc.section.9.10.3.p.4"><p>If the lock cannot be granted to all resources, the server <em class="bcp14">MUST</em>
 return a Multi-Status response with a 'response' element for at least 
one resource that prevented the lock from being granted, along with a 
suitable status code for that failure (e.g., 403 (Forbidden) or 423 
(Locked)). Additionally, if the resource causing the failure was not the
 resource requested, then the server <em class="bcp14">SHOULD</em> include a 'response' element for the Request-URI as well, with a 'status' element containing 424 Failed Dependency.<a class="self" href="#rfc.section.9.10.3.p.4">¶</a></p></div><div id="rfc.section.9.10.3.p.5"><p>If no Depth header is submitted on a LOCK request, then the request <em class="bcp14">MUST</em> act as if a "Depth:infinity" had been submitted.<a class="self" href="#rfc.section.9.10.3.p.5">¶</a></p></div></section><section id="n-locking-unmapped-urls"><h4 id="rfc.section.9.10.4"><a href="#rfc.section.9.10.4">9.10.4</a>&nbsp;<a href="#n-locking-unmapped-urls">Locking Unmapped URLs</a></h4><div id="rfc.section.9.10.4.p.1"><p>A successful LOCK method <em class="bcp14">MUST</em>
 result in the creation of an empty resource that is locked (and that is
 not a collection) when a resource did not previously exist at that URL.
 Later on, the lock may go away but the empty resource remains. Empty 
resources <em class="bcp14">MUST</em> then appear in PROPFIND responses including that URL in the response scope. A server <em class="bcp14">MUST</em>
 respond successfully to a GET request to an empty resource, either by 
using a 204 No Content response, or by using 200 OK with a 
Content-Length header indicating zero length<a class="self" href="#rfc.section.9.10.4.p.1">¶</a></p></div></section><section id="n-lock-compatibility-table"><h4 id="rfc.section.9.10.5"><a href="#rfc.section.9.10.5">9.10.5</a>&nbsp;<a href="#n-lock-compatibility-table">Lock Compatibility Table</a></h4><div id="rfc.section.9.10.5.p.1"><p>The table below describes the behavior that occurs when a lock request is made on a resource.<a class="self" href="#rfc.section.9.10.5.p.1">¶</a></p></div><div id="rfc.table.u.1" class="tt"><table class="tt full tcenter"><thead><tr><th style="width: 40%;">Current State</th><th>Shared Lock OK</th><th>Exclusive Lock OK</th></tr></thead><tbody><tr><td class="left">None</td><td class="left">True</td><td class="left">True</td></tr><tr><td class="left">Shared Lock</td><td class="left">True</td><td class="left">False</td></tr><tr><td class="left">Exclusive Lock</td><td class="left">False</td><td class="left">False*</td></tr></tbody></table></div><div id="rfc.section.9.10.5.p.2"><p>Legend: True = lock may be granted. False = lock <em class="bcp14">MUST NOT</em> be granted. *=It is illegal for a principal to request the same lock twice.<a class="self" href="#rfc.section.9.10.5.p.2">¶</a></p></div><div id="rfc.section.9.10.5.p.3"><p>The
 current lock state of a resource is given in the leftmost column, and 
lock requests are listed in the first row. The intersection of a row and
 column gives the result of a lock request. For example, if a shared 
lock is held on a resource, and an exclusive lock is requested, the 
table entry is "false", indicating that the lock must not be granted.<a class="self" href="#rfc.section.9.10.5.p.3">¶</a></p></div></section><section id="n-lock-responses"><h4 id="rfc.section.9.10.6"><a href="#rfc.section.9.10.6">9.10.6</a>&nbsp;<a href="#n-lock-responses">LOCK Responses</a></h4><div id="rfc.section.9.10.6.p.1" class="avoidbreakafter"><p>In addition to the general status codes possible, the following status codes have specific applicability to LOCK:<a class="self" href="#rfc.section.9.10.6.p.1">¶</a></p></div><div id="rfc.section.9.10.6.p.2"><p>200 (OK) - The LOCK request succeeded and the value of the DAV:lockdiscovery property is included in the response body.<a class="self" href="#rfc.section.9.10.6.p.2">¶</a></p></div><div id="rfc.section.9.10.6.p.3"><p>201
 (Created) - The LOCK request was to an unmapped URL, the request 
succeeded and resulted in the creation of a new resource, and the value 
of the DAV:lockdiscovery property is included in the response body.<a class="self" href="#rfc.section.9.10.6.p.3">¶</a></p></div><div id="rfc.section.9.10.6.p.4"><p>409
 (Conflict) - A resource cannot be created at the destination until one 
or more intermediate collections have been created. The server <em class="bcp14">MUST NOT</em> create those intermediate collections automatically.<a class="self" href="#rfc.section.9.10.6.p.4">¶</a></p></div><div id="rfc.section.9.10.6.p.5"><p>423
 (Locked), potentially with 'no-conflicting-lock' precondition code - 
There is already a lock on the resource that is not compatible with the 
requested lock (see lock compatibility table above).<a class="self" href="#rfc.section.9.10.6.p.5">¶</a></p></div><div id="rfc.section.9.10.6.p.6"><p>412
 (Precondition Failed), with 'lock-token-matches-request-uri' 
precondition code - The LOCK request was made with an If header, 
indicating that the client wishes to refresh the given lock. However, 
the Request-URI did not fall within the scope of the lock identified by 
the token. The lock may have a scope that does not include the 
Request-URI, or the lock could have disappeared, or the token may be 
invalid.<a class="self" href="#rfc.section.9.10.6.p.6">¶</a></p></div></section><section id="n-example---simple-lock-request"><h4 id="rfc.section.9.10.7"><a href="#rfc.section.9.10.7">9.10.7</a>&nbsp;<a href="#n-example---simple-lock-request">Example - Simple Lock Request</a></h4><div id="rfc.figure.u.36"><p>&gt;&gt;Request</p><pre class="text2">  LOCK /workspace/webdav/proposal.doc HTTP/1.1 
  Host: example.com 
  Timeout: Infinite, Second-4100000000 
  Content-Type: application/xml; charset="utf-8" 
  Content-Length: xxxx 
  Authorization: Digest username="ejw", 
    realm="ejw@example.com", nonce="...", 
    uri="/workspace/webdav/proposal.doc", 
    response="...", opaque="..." 
    
  &lt;?xml version="1.0" encoding="utf-8" ?&gt; 
  &lt;D:lockinfo xmlns:D='DAV:'&gt; 
    &lt;D:lockscope&gt;&lt;D:exclusive/&gt;&lt;/D:lockscope&gt; 
    &lt;D:locktype&gt;&lt;D:write/&gt;&lt;/D:locktype&gt; 
    &lt;D:owner&gt; 
      &lt;D:href&gt;http://example.org/~ejw/contact.html&lt;/D:href&gt; 
    &lt;/D:owner&gt; 
  &lt;/D:lockinfo&gt; 
</pre></div><div id="rfc.figure.u.37"><p>&gt;&gt;Response</p><pre class="text">  HTTP/1.1 200 OK 
  Lock-Token: &lt;urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4&gt; 
  Content-Type: application/xml; charset="utf-8" 
  Content-Length: xxxx 
  
  &lt;?xml version="1.0" encoding="utf-8" ?&gt; 
  &lt;D:prop xmlns:D="DAV:"&gt; 
    &lt;D:lockdiscovery&gt; 
      &lt;D:activelock&gt; 
        &lt;D:locktype&gt;&lt;D:write/&gt;&lt;/D:locktype&gt; 
        &lt;D:lockscope&gt;&lt;D:exclusive/&gt;&lt;/D:lockscope&gt; 
        &lt;D:depth&gt;infinity&lt;/D:depth&gt; 
        &lt;D:owner&gt; 
          &lt;D:href&gt;http://example.org/~ejw/contact.html&lt;/D:href&gt; 
        &lt;/D:owner&gt; 
        &lt;D:timeout&gt;Second-604800&lt;/D:timeout&gt; 
        &lt;D:locktoken&gt; 
          &lt;D:href
          &gt;urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4&lt;/D:href&gt;
        &lt;/D:locktoken&gt; 
        &lt;D:lockroot&gt; 
          &lt;D:href
          &gt;http://example.com/workspace/webdav/proposal.doc&lt;/D:href&gt;
        &lt;/D:lockroot&gt; 
      &lt;/D:activelock&gt; 
    &lt;/D:lockdiscovery&gt; 
  &lt;/D:prop&gt; 
</pre></div><div id="rfc.section.9.10.7.p.1"><p>This example shows the 
successful creation of an exclusive write lock on resource 
http://example.com/workspace/webdav/proposal.doc. The resource 
http://example.org/~ejw/contact.html contains contact information for 
the creator of the lock. The server has an activity-based timeout policy
 in place on this resource, which causes the lock to automatically be 
removed after 1 week (604800 seconds). Note that the nonce, response, 
and opaque fields have not been calculated in the Authorization request 
header.<a class="self" href="#rfc.section.9.10.7.p.1">¶</a></p></div></section><section id="n-example---refreshing-a-write-lock"><h4 id="rfc.section.9.10.8"><a href="#rfc.section.9.10.8">9.10.8</a>&nbsp;<a href="#n-example---refreshing-a-write-lock">Example - Refreshing a Write Lock</a></h4><div id="rfc.figure.u.38"><p>&gt;&gt;Request</p><pre class="text2">  LOCK /workspace/webdav/proposal.doc HTTP/1.1 
  Host: example.com 
  Timeout: Infinite, Second-4100000000 
  If: (&lt;urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4&gt;) 
  Authorization: Digest username="ejw", 
    realm="ejw@example.com", nonce="...", 
    uri="/workspace/webdav/proposal.doc", 
    response="...", opaque="..." 
</pre></div><div id="rfc.figure.u.39"><p>&gt;&gt;Response</p><pre class="text">  HTTP/1.1 200 OK 
  Content-Type: application/xml; charset="utf-8" 
  Content-Length: xxxx 
  
  &lt;?xml version="1.0" encoding="utf-8" ?&gt; 
  &lt;D:prop xmlns:D="DAV:"&gt; 
    &lt;D:lockdiscovery&gt; 
      &lt;D:activelock&gt; 
        &lt;D:locktype&gt;&lt;D:write/&gt;&lt;/D:locktype&gt; 
        &lt;D:lockscope&gt;&lt;D:exclusive/&gt;&lt;/D:lockscope&gt; 
        &lt;D:depth&gt;infinity&lt;/D:depth&gt; 
        &lt;D:owner&gt; 
          &lt;D:href&gt;http://example.org/~ejw/contact.html&lt;/D:href&gt; 
        &lt;/D:owner&gt; 
        &lt;D:timeout&gt;Second-604800&lt;/D:timeout&gt; 
        &lt;D:locktoken&gt; 
          &lt;D:href
          &gt;urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4&lt;/D:href&gt; 
        &lt;/D:locktoken&gt; 
        &lt;D:lockroot&gt; 
          &lt;D:href
          &gt;http://example.com/workspace/webdav/proposal.doc&lt;/D:href&gt; 
        &lt;/D:lockroot&gt; 
      &lt;/D:activelock&gt; 
    &lt;/D:lockdiscovery&gt; 
  &lt;/D:prop&gt; 
</pre><p>This request would refresh the lock, attempting to reset the 
timeout to the new value specified in the timeout header. Notice that 
the client asked for an infinite time out but the server choose to 
ignore the request. In this example, the nonce, response, and opaque 
fields have not been calculated in the Authorization request header.</p></div></section><section id="n-example---multi-resource-lock-request"><h4 id="rfc.section.9.10.9"><a href="#rfc.section.9.10.9">9.10.9</a>&nbsp;<a href="#n-example---multi-resource-lock-request">Example - Multi-Resource Lock Request</a></h4><div id="rfc.figure.u.40"><p>&gt;&gt;Request</p><pre class="text2">  LOCK /webdav/ HTTP/1.1 
  Host: example.com 
  Timeout: Infinite, Second-4100000000 
  Depth: infinity 
  Content-Type: application/xml; charset="utf-8" 
  Content-Length: xxxx 
  Authorization: Digest username="ejw", 
    realm="ejw@example.com", nonce="...", 
    uri="/workspace/webdav/proposal.doc", 
    response="...", opaque="..." 
      
  &lt;?xml version="1.0" encoding="utf-8" ?&gt; 
  &lt;D:lockinfo xmlns:D="DAV:"&gt; 
    &lt;D:locktype&gt;&lt;D:write/&gt;&lt;/D:locktype&gt; 
    &lt;D:lockscope&gt;&lt;D:exclusive/&gt;&lt;/D:lockscope&gt; 
    &lt;D:owner&gt; 
      &lt;D:href&gt;http://example.org/~ejw/contact.html&lt;/D:href&gt; 
    &lt;/D:owner&gt; 
  &lt;/D:lockinfo&gt; 
</pre></div><div id="rfc.figure.u.41"><p>&gt;&gt;Response</p><pre class="text">  HTTP/1.1 207 Multi-Status 
  Content-Type: application/xml; charset="utf-8" 
  Content-Length: xxxx 
  
  &lt;?xml version="1.0" encoding="utf-8" ?&gt; 
  &lt;D:multistatus xmlns:D="DAV:"&gt; 
    &lt;D:response&gt; 
      &lt;D:href&gt;http://example.com/webdav/secret&lt;/D:href&gt; 
      &lt;D:status&gt;HTTP/1.1 403 Forbidden&lt;/D:status&gt; 
    &lt;/D:response&gt; 
    &lt;D:response&gt; 
      &lt;D:href&gt;http://example.com/webdav/&lt;/D:href&gt; 
      &lt;D:status&gt;HTTP/1.1 424 Failed Dependency&lt;/D:status&gt; 
    &lt;/D:response&gt; 
  &lt;/D:multistatus&gt;      
</pre></div><div id="rfc.section.9.10.9.p.1"><p>This example shows a 
request for an exclusive write lock on a collection and all its 
children. In this request, the client has specified that it desires an 
infinite-length lock, if available, otherwise a timeout of 4.1 billion 
seconds, if available. The request entity body contains the contact 
information for the principal taking out the lock -- in this case, a Web
 page URL.<a class="self" href="#rfc.section.9.10.9.p.1">¶</a></p></div><div id="rfc.section.9.10.9.p.2"><p>The
 error is a 403 (Forbidden) response on the resource 
http://example.com/webdav/secret. Because this resource could not be 
locked, none of the resources were locked. Note also that the a 
'response' element for the Request-URI itself has been included as 
required.<a class="self" href="#rfc.section.9.10.9.p.2">¶</a></p></div><div id="rfc.section.9.10.9.p.3"><p>In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.<a class="self" href="#rfc.section.9.10.9.p.3">¶</a></p></div></section></section><section id="METHOD_UNLOCK"><h3 id="rfc.section.9.11"><a href="#rfc.section.9.11">9.11</a>&nbsp;<a href="#METHOD_UNLOCK">UNLOCK Method</a></h3><div id="rfc.section.9.11.p.1"><p>The UNLOCK method removes the lock identified by the lock token in the Lock-Token request header. The Request-URI <em class="bcp14">MUST</em> identify a resource within the scope of the lock.<a class="self" href="#rfc.section.9.11.p.1">¶</a></p></div><div id="rfc.section.9.11.p.2"><p>Note
 that use of the Lock-Token header to provide the lock token is not 
consistent with other state-changing methods, which all require an If 
header with the lock token. Thus, the If header is not needed to provide
 the lock token. Naturally, when the If header is present, it has its 
normal meaning as a conditional header.<a class="self" href="#rfc.section.9.11.p.2">¶</a></p></div><div id="rfc.section.9.11.p.3"><p>For a successful response to this method, the server <em class="bcp14">MUST</em> delete the lock entirely.<a class="self" href="#rfc.section.9.11.p.3">¶</a></p></div><div id="rfc.section.9.11.p.4"><p>If all resources that have been locked under the submitted lock token cannot be unlocked, then the UNLOCK request <em class="bcp14">MUST</em> fail.<a class="self" href="#rfc.section.9.11.p.4">¶</a></p></div><div id="rfc.section.9.11.p.5"><p>A
 successful response to an UNLOCK method does not mean that the resource
 is necessarily unlocked. It means that the specific lock corresponding 
to the specified token no longer exists.<a class="self" href="#rfc.section.9.11.p.5">¶</a></p></div><div id="rfc.section.9.11.p.6"><p>Any DAV-compliant resource that supports the LOCK method <em class="bcp14">MUST</em> support the UNLOCK method.<a class="self" href="#rfc.section.9.11.p.6">¶</a></p></div><div id="rfc.section.9.11.p.7"><p>This method is idempotent, but not safe (see <a href="https://tools.ietf.org/html/rfc2616#section-9.1">Section 9.1</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.20"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>). Responses to this method <em class="bcp14">MUST NOT</em> be cached.<a class="self" href="#rfc.section.9.11.p.7">¶</a></p></div><section id="n-status-codes_3"><h4 id="rfc.section.9.11.1"><a href="#rfc.section.9.11.1">9.11.1</a>&nbsp;<a href="#n-status-codes_3">Status Codes</a></h4><div id="rfc.section.9.11.1.p.1" class="avoidbreakafter"><p>In addition to the general status codes possible, the following status codes have specific applicability to UNLOCK:<a class="self" href="#rfc.section.9.11.1.p.1">¶</a></p></div><div id="rfc.section.9.11.1.p.2"><p>204
 (No Content) - Normal success response (rather than 200 OK, since 200 
OK would imply a response body, and an UNLOCK success response does not 
normally contain a body).<a class="self" href="#rfc.section.9.11.1.p.2">¶</a></p></div><div id="rfc.section.9.11.1.p.3"><p>400 (Bad Request) - No lock token was provided.<a class="self" href="#rfc.section.9.11.1.p.3">¶</a></p></div><div id="rfc.section.9.11.1.p.4"><p>403 (Forbidden) - The currently authenticated principal does not have permission to remove the lock.<a class="self" href="#rfc.section.9.11.1.p.4">¶</a></p></div><div id="rfc.section.9.11.1.p.5"><p>409
 (Conflict), with 'lock-token-matches-request-uri' precondition - The 
resource was not locked, or the request was made to a Request-URI that 
was not within the scope of the lock.<a class="self" href="#rfc.section.9.11.1.p.5">¶</a></p></div></section><section id="n-example---unlock"><h4 id="rfc.section.9.11.2"><a href="#rfc.section.9.11.2">9.11.2</a>&nbsp;<a href="#n-example---unlock">Example - UNLOCK</a></h4><div id="rfc.figure.u.42"><p>&gt;&gt;Request</p><pre class="text2">  UNLOCK /workspace/webdav/info.doc HTTP/1.1 
  Host: example.com 
  Lock-Token: &lt;urn:uuid:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7&gt; 
  Authorization: Digest username="ejw" 
    realm="ejw@example.com", nonce="...", 
    uri="/workspace/webdav/proposal.doc", 
    response="...", opaque="..." 
</pre></div><div id="rfc.figure.u.43"><p>&gt;&gt;Response</p><pre class="text">  HTTP/1.1 204 No Content 
</pre></div><div id="rfc.section.9.11.2.p.1"><p>In this example, the 
lock identified by the lock token 
"urn:uuid:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is successfully removed 
from the resource http://example.com/workspace/webdav/info.doc. If this 
lock included more than just one resource, the lock is removed from all 
resources included in the lock.<a class="self" href="#rfc.section.9.11.2.p.1">¶</a></p></div><div id="rfc.section.9.11.2.p.2"><p>In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.<a class="self" href="#rfc.section.9.11.2.p.2">¶</a></p></div></section></section></section><section id="http.headers.for.distributed.authoring"><h2 id="rfc.section.10"><a href="#rfc.section.10">10.</a>&nbsp;<a href="#http.headers.for.distributed.authoring">HTTP Headers for Distributed Authoring</a></h2><div id="rfc.section.10.p.1"><p>All
 DAV headers follow the same basic formatting rules as HTTP headers. 
This includes rules like line continuation and how to combine (or 
separate) multiple instances of the same header using commas.<a class="self" href="#rfc.section.10.p.1">¶</a></p></div><div id="rfc.section.10.p.2"><p>WebDAV adds two new conditional headers to the set defined in HTTP: the If and Overwrite headers.<a class="self" href="#rfc.section.10.p.2">¶</a></p></div><section id="HEADER_DAV"><h3 id="rfc.section.10.1"><a href="#rfc.section.10.1">10.1</a>&nbsp;<a href="#HEADER_DAV">DAV Header</a></h3><div id="rfc.figure.u.44"><pre class="inline">  DAV              = "DAV" ":" #( compliance-class ) 
  compliance-class = ( "1" | "2" | "3" | extend ) 
  extend           = Coded-URL | token 
                     ; token is defined in RFC 2616, <a href="https://tools.ietf.org/html/rfc2616#section-2.2" id="rfc.xref.RFC2616.21">Section 2.2</a>
  Coded-URL        = "&lt;" absolute-URI "&gt;" 
                     ; No linear whitespace (LWS) allowed in Coded-URL
                     ; absolute-URI defined in RFC 3986, <a href="https://tools.ietf.org/html/rfc3986#section-4.3" id="rfc.xref.RFC3986.11">Section 4.3</a> 
</pre></div><div id="rfc.section.10.1.p.1"><p>This general-header 
appearing in the response indicates that the resource supports the DAV 
schema and protocol as specified. All DAV-compliant resources <em class="bcp14">MUST</em>
 return the DAV header with compliance-class "1" on all OPTIONS 
responses. In cases where WebDAV is only supported in part of the server
 namespace, an OPTIONS request to non-WebDAV resources (including "/") <em class="bcp14">SHOULD NOT</em> advertise WebDAV support.<a class="self" href="#rfc.section.10.1.p.1">¶</a></p></div><div id="rfc.section.10.1.p.2"><p>The
 value is a comma-separated list of all compliance class identifiers 
that the resource supports. Class identifiers may be Coded-URLs or 
tokens (as defined by <a href="#RFC2616" id="rfc.xref.RFC2616.22"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>).
 Identifiers can appear in any order. Identifiers that are standardized 
through the IETF RFC process are tokens, but other identifiers <em class="bcp14">SHOULD</em> be Coded-URLs to encourage uniqueness.<a class="self" href="#rfc.section.10.1.p.2">¶</a></p></div><div id="rfc.section.10.1.p.3"><p>A
 resource must show class 1 compliance if it shows class 2 or 3 
compliance. In general, support for one compliance class does not entail
 support for any other, and in particular, support for compliance class 3
 does not require support for compliance class 2. Please refer to <a href="#dav.compliance.classes" title="DAV Compliance Classes">Section&nbsp;18</a> for more details on compliance classes defined in this specification.<a class="self" href="#rfc.section.10.1.p.3">¶</a></p></div><div id="rfc.section.10.1.p.4"><p>Note that many WebDAV servers do not advertise WebDAV support in response to "OPTIONS *".<a class="self" href="#rfc.section.10.1.p.4">¶</a></p></div><div id="rfc.section.10.1.p.5"><p>As
 a request header, this header allows the client to advertise compliance
 with named features when the server needs that information. Clients <em class="bcp14">SHOULD NOT</em>
 send this header unless a standards track specification requires it. 
Any extension that makes use of this as a request header will need to 
carefully consider caching implications.<a class="self" href="#rfc.section.10.1.p.5">¶</a></p></div></section><section id="HEADER_Depth"><h3 id="rfc.section.10.2"><a href="#rfc.section.10.2">10.2</a>&nbsp;<a href="#HEADER_Depth">Depth Header</a></h3><div id="rfc.figure.u.45"><pre class="inline">   Depth = "Depth" ":" ("0" | "1" | "infinity")
</pre></div><div id="rfc.section.10.2.p.1"><p>The Depth request header 
is used with methods executed on resources that could potentially have 
internal members to indicate whether the method is to be applied only to
 the resource ("Depth: 0"), to the resource and its internal members 
only ("Depth: 1"), or the resource and all its members ("Depth: 
infinity").<a class="self" href="#rfc.section.10.2.p.1">¶</a></p></div><div id="rfc.section.10.2.p.2"><p>The Depth header is only supported if a method's definition explicitly provides for such support.<a class="self" href="#rfc.section.10.2.p.2">¶</a></p></div><div id="rfc.section.10.2.p.3"><p>The
 following rules are the default behavior for any method that supports 
the Depth header. A method may override these defaults by defining 
different behavior in its definition.<a class="self" href="#rfc.section.10.2.p.3">¶</a></p></div><div id="rfc.section.10.2.p.4"><p>Methods
 that support the Depth header may choose not to support all of the 
header's values and may define, on a case-by-case basis, the behavior of
 the method if a Depth header is not present. For example, the MOVE 
method only supports "Depth: infinity", and if a Depth header is not 
present, it will act as if a "Depth: infinity" header had been applied.<a class="self" href="#rfc.section.10.2.p.4">¶</a></p></div><div id="rfc.section.10.2.p.5"><p>Clients <em class="bcp14">MUST NOT</em>
 rely upon methods executing on members of their hierarchies in any 
particular order or on the execution being atomic unless the particular 
method explicitly provides such guarantees.<a class="self" href="#rfc.section.10.2.p.5">¶</a></p></div><div id="rfc.section.10.2.p.6"><p>Upon
 execution, a method with a Depth header will perform as much of its 
assigned task as possible and then return a response specifying what it 
was able to accomplish and what it failed to do.<a class="self" href="#rfc.section.10.2.p.6">¶</a></p></div><div id="rfc.section.10.2.p.7"><p>So, for example, an attempt to COPY a hierarchy may result in some of the members being copied and some not.<a class="self" href="#rfc.section.10.2.p.7">¶</a></p></div><div id="rfc.section.10.2.p.8"><p>By default, the Depth header does not interact with other headers. That is, each header on a request with a Depth header <em class="bcp14">MUST</em> be applied only to the Request-URI if it applies to any resource, unless specific Depth behavior is defined for that header.<a class="self" href="#rfc.section.10.2.p.8">¶</a></p></div><div id="rfc.section.10.2.p.9"><p>If
 a source or destination resource within the scope of the Depth header 
is locked in such a way as to prevent the successful execution of the 
method, then the lock token for that resource <em class="bcp14">MUST</em> be submitted with the request in the If request header.<a class="self" href="#rfc.section.10.2.p.9">¶</a></p></div><div id="rfc.section.10.2.p.10"><p>The
 Depth header only specifies the behavior of the method with regards to 
internal members. If a resource does not have internal members, then the
 Depth header <em class="bcp14">MUST</em> be ignored.<a class="self" href="#rfc.section.10.2.p.10">¶</a></p></div></section><section id="HEADER_Destination"><h3 id="rfc.section.10.3"><a href="#rfc.section.10.3">10.3</a>&nbsp;<a href="#HEADER_Destination">Destination Header</a></h3><div id="rfc.section.10.3.p.1"><p>The
 Destination request header specifies the URI that identifies a 
destination resource for methods such as COPY and MOVE, which take two 
URIs as parameters.<a class="self" href="#rfc.section.10.3.p.1">¶</a></p></div><div id="rfc.figure.u.46"><pre class="inline">   Destination = "Destination" ":" <a href="#simple-ref" class="smpl">Simple-ref</a>
</pre></div><div id="rfc.section.10.3.p.2"><p>If the Destination value is an absolute-URI (<a href="https://tools.ietf.org/html/rfc3986#section-4.3">Section 4.3</a> of <a href="#RFC3986" id="rfc.xref.RFC3986.12"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>),
 it may name a different server (or different port or scheme). If the 
source server cannot attempt a copy to the remote server, it <em class="bcp14">MUST</em>
 fail the request. Note that copying and moving resources to remote 
servers is not fully defined in this specification (e.g., specific error
 conditions).<a class="self" href="#rfc.section.10.3.p.2">¶</a></p></div><div id="rfc.section.10.3.p.3"><p>If the Destination value is too long or otherwise unacceptable, the server <em class="bcp14">SHOULD</em> return 400 (Bad Request), ideally with helpful information in an error body.<a class="self" href="#rfc.section.10.3.p.3">¶</a></p></div></section><section id="HEADER_If"><h3 id="rfc.section.10.4"><a href="#rfc.section.10.4">10.4</a>&nbsp;<a href="#HEADER_If">If Header</a></h3><div id="rfc.section.10.4.p.1"><p>The If request header is intended to have similar functionality to the If-Match header defined in <a href="https://tools.ietf.org/html/rfc2616#section-14.24">Section 14.24</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.23"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.
 However, the If header handles any state token as well as ETags. A 
typical example of a state token is a lock token, and lock tokens are 
the only state tokens defined in this specification.<a class="self" href="#rfc.section.10.4.p.1">¶</a></p></div><section id="if.header.purpose"><h4 id="rfc.section.10.4.1"><a href="#rfc.section.10.4.1">10.4.1</a>&nbsp;<a href="#if.header.purpose">Purpose</a></h4><div id="rfc.section.10.4.1.p.1"><p>The If header has two distinct purposes: <a class="self" href="#rfc.section.10.4.1.p.1">¶</a></p><ul><li>The
 first purpose is to make a request conditional by supplying a series of
 state lists with conditions that match tokens and ETags to a specific 
resource. If this header is evaluated and all state lists fail, then the
 request <em class="bcp14">MUST</em> fail with a 412 (Precondition 
Failed) status. On the other hand, the request can succeed only if one 
of the described state lists succeeds. The success criteria for state 
lists and matching functions are defined in Sections <a href="#if.header.evaluation" title="List Evaluation">10.4.3</a> and <a href="#if.header.matching.function" title="Matching State Tokens and ETags">10.4.4</a>.</li><li>Additionally,
 the mere fact that a state token appears in an If header means that it 
has been "submitted" with the request. In general, this is used to 
indicate that the client has knowledge of that state token. The 
semantics for submitting a state token depend on its type (for lock 
tokens, please refer to <a href="#locking" title="Locking">Section&nbsp;6</a>).</li></ul></div><div id="rfc.section.10.4.1.p.2"><p>Note
 that these two purposes need to be treated distinctly: a state token 
counts as being submitted independently of whether the server actually 
has evaluated the state list it appears in, and also independently of 
whether or not the condition it expressed was found to be true.<a class="self" href="#rfc.section.10.4.1.p.2">¶</a></p></div></section><section id="if.header.syntax"><h4 id="rfc.section.10.4.2"><a href="#rfc.section.10.4.2">10.4.2</a>&nbsp;<a href="#if.header.syntax">Syntax</a></h4><div id="rfc.figure.u.47"><pre class="inline">  If = "If" ":" ( 1*No-tag-list | 1*Tagged-list ) 
  
  No-tag-list = List
  Tagged-list = Resource-Tag 1*List
  
  List = "(" 1*Condition ")"
  Condition = ["Not"] (State-token | "[" entity-tag "]")
  ; entity-tag: see <a href="https://tools.ietf.org/html/rfc2616#section-3.11">Section 3.11</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.24"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>
  ; No LWS allowed between "[", entity-tag and "]"
  
  State-token = Coded-URL
  
  Resource-Tag = "&lt;" <a href="#simple-ref" class="smpl">Simple-ref</a> "&gt;" 
  ; <a href="#simple-ref" class="smpl">Simple-ref</a>: see <a href="#url-handling" title="URL Handling">Section&nbsp;8.3</a>
  ; No LWS allowed in Resource-Tag</pre></div><div id="rfc.section.10.4.2.p.1"><p>The
 syntax distinguishes between untagged lists ("No-tag-list") and tagged 
lists ("Tagged-list"). Untagged lists apply to the resource identified 
by the Request-URI, while tagged lists apply to the resource identified 
by the preceding Resource-Tag.<a class="self" href="#rfc.section.10.4.2.p.1">¶</a></p></div><div id="rfc.section.10.4.2.p.2"><p>A Resource-Tag applies to all subsequent Lists, up to the next Resource-Tag.<a class="self" href="#rfc.section.10.4.2.p.2">¶</a></p></div><div id="rfc.section.10.4.2.p.3"><p>Note
 that the two list types cannot be mixed within an If header. This is 
not a functional restriction because the No-tag-list syntax is just a 
shorthand notation for a Tagged-list production with a Resource-Tag 
referring to the Request-URI.<a class="self" href="#rfc.section.10.4.2.p.3">¶</a></p></div><div id="rfc.section.10.4.2.p.4"><p>Each
 List consists of one or more Conditions. Each Condition is defined in 
terms of an entity-tag or state-token, potentially negated by the prefix
 "Not".<a class="self" href="#rfc.section.10.4.2.p.4">¶</a></p></div><div id="rfc.section.10.4.2.p.5"><p>Note
 that the If header syntax does not allow multiple instances of If 
headers in a single request. However, the HTTP header syntax allows 
extending single header values across multiple lines, by inserting a 
line break followed by whitespace (see <a href="#RFC2616" id="rfc.xref.RFC2616.25"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="https://tools.ietf.org/html/rfc2616#section-4.2">Section 4.2</a>).<a class="self" href="#rfc.section.10.4.2.p.5">¶</a></p></div></section><section id="if.header.evaluation"><h4 id="rfc.section.10.4.3"><a href="#rfc.section.10.4.3">10.4.3</a>&nbsp;<a href="#if.header.evaluation">List Evaluation</a></h4><div id="rfc.section.10.4.3.p.1"><p>A
 Condition that consists of a single entity-tag or state-token evaluates
 to true if the resource matches the described state (where the 
individual matching functions are defined below in <a href="#if.header.matching.function" title="Matching State Tokens and ETags">Section&nbsp;10.4.4</a>).
 Prefixing it with "Not" reverses the result of the evaluation (thus, 
the "Not" applies only to the subsequent entity-tag or state-token).<a class="self" href="#rfc.section.10.4.3.p.1">¶</a></p></div><div id="rfc.section.10.4.3.p.2"><p>Each
 List production describes a series of conditions. The whole list 
evaluates to true if and only if each condition evaluates to true (that 
is, the list represents a logical conjunction of Conditions).<a class="self" href="#rfc.section.10.4.3.p.2">¶</a></p></div><div id="rfc.section.10.4.3.p.3"><p>Each
 No-tag-list and Tagged-list production may contain one or more Lists. 
They evaluate to true if and only if any of the contained lists 
evaluates to true (that is, if there's more than one List, that List 
sequence represents a logical disjunction of the Lists).<a class="self" href="#rfc.section.10.4.3.p.3">¶</a></p></div><div id="rfc.section.10.4.3.p.4"><p>Finally,
 the whole If header evaluates to true if and only if at least one of 
the No-tag-list or Tagged-list productions evaluates to true. If the 
header evaluates to false, the server <em class="bcp14">MUST</em> reject
 the request with a 412 (Precondition Failed) status. Otherwise, 
execution of the request can proceed as if the header wasn't present.<a class="self" href="#rfc.section.10.4.3.p.4">¶</a></p></div></section><section id="if.header.matching.function"><h4 id="rfc.section.10.4.4"><a href="#rfc.section.10.4.4">10.4.4</a>&nbsp;<a href="#if.header.matching.function">Matching State Tokens and ETags</a></h4><div id="rfc.section.10.4.4.p.1" class="avoidbreakafter"><p>When performing If header processing, the definition of a matching state token or entity tag is as follows:<a class="self" href="#rfc.section.10.4.4.p.1">¶</a></p></div><div id="rfc.section.10.4.4.p.2"><p>Identifying
 a resource: The resource is identified by the URI along with the token,
 in tagged list production, or by the Request-URI in untagged list 
production.<a class="self" href="#rfc.section.10.4.4.p.2">¶</a></p></div><div id="rfc.section.10.4.4.p.3"><p>Matching entity tag: Where the entity tag matches an entity tag associated with the identified resource. Servers <em class="bcp14">MUST</em> use either the weak or the strong comparison function defined in <a href="https://tools.ietf.org/html/rfc2616#section-13.3.3">Section 13.3.3</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.26"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.<a class="self" href="#rfc.section.10.4.4.p.3">¶</a></p></div><div id="rfc.section.10.4.4.p.4"><p>Matching
 state token: Where there is an exact match between the state token in 
the If header and any state token on the identified resource. A lock 
state token is considered to match if the resource is anywhere in the 
scope of the lock.<a class="self" href="#rfc.section.10.4.4.p.4">¶</a></p></div><div id="rfc.section.10.4.4.p.5"><p>Handling
 unmapped URLs: For both ETags and state tokens, treat as if the URL 
identified a resource that exists but does not have the specified state.<a class="self" href="#rfc.section.10.4.4.p.5">¶</a></p></div></section><section id="n-if-header-and-non-dav-aware-proxies"><h4 id="rfc.section.10.4.5"><a href="#rfc.section.10.4.5">10.4.5</a>&nbsp;<a href="#n-if-header-and-non-dav-aware-proxies">If Header and Non-DAV-Aware Proxies</a></h4><div id="rfc.section.10.4.5.p.1"><p>Non-DAV-aware
 proxies will not honor the If header, since they will not understand 
the If header, and HTTP requires non-understood headers to be ignored. 
When communicating with HTTP/1.1 proxies, the client <em class="bcp14">MUST</em>
 use the "Cache-Control: no-cache" request header so as to prevent the 
proxy from improperly trying to service the request from its cache. When
 dealing with HTTP/1.0 proxies, the "Pragma: no-cache" request header <em class="bcp14">MUST</em> be used for the same reason.<a class="self" href="#rfc.section.10.4.5.p.1">¶</a></p></div><div id="rfc.section.10.4.5.p.2"><p>Because
 in general clients may not be able to reliably detect non-DAV-aware 
intermediates, they are advised to always prevent caching using the 
request directives mentioned above.<a class="self" href="#rfc.section.10.4.5.p.2">¶</a></p></div></section><section id="if.header.evaluation.example.no-tag"><h4 id="rfc.section.10.4.6"><a href="#rfc.section.10.4.6">10.4.6</a>&nbsp;<a href="#if.header.evaluation.example.no-tag">Example - No-tag Production</a></h4><div id="rfc.figure.u.48"><pre class="text">  If: (&lt;urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2&gt; 
    ["I am an ETag"])
    (["I am another ETag"])</pre></div><div id="rfc.section.10.4.6.p.1"><p>The
 previous header would require that the resource identified in the 
Request-URI be locked with the specified lock token and be in the state 
identified by the "I am an ETag" ETag or in the state identified by the 
second ETag "I am another ETag".<a class="self" href="#rfc.section.10.4.6.p.1">¶</a></p></div><div id="rfc.figure.u.49"><p>To put the matter more plainly one can think of the previous If header as expressing the condition below:</p><pre class="text">  ( 
    is-locked-with(urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2) AND
    matches-etag("I am an ETag")
  )
  OR
  (
    matches-etag("I am another ETag")
  )</pre></div></section><section><h4 id="rfc.section.10.4.7"><a href="#rfc.section.10.4.7">10.4.7</a>&nbsp;Example - Using "Not" with No-tag Production</h4><div id="rfc.figure.u.50"><pre class="text">  If: (Not &lt;urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2&gt; 
  &lt;urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092&gt;)</pre></div><div id="rfc.section.10.4.7.p.1"><p>This
 If header requires that the resource must not be locked with a lock 
having the lock token urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2 and 
must be locked by a lock with the lock token 
urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092.<a class="self" href="#rfc.section.10.4.7.p.1">¶</a></p></div></section><section id="n-example---causing-a-condition-to-always-evaluate-to-true"><h4 id="rfc.section.10.4.8"><a href="#rfc.section.10.4.8">10.4.8</a>&nbsp;<a href="#n-example---causing-a-condition-to-always-evaluate-to-true">Example - Causing a Condition to Always Evaluate to True</a></h4><div id="rfc.section.10.4.8.p.1" class="avoidbreakafter"><p>There
 may be cases where a client wishes to submit state tokens, but doesn't 
want the request to fail just because the state token isn't current 
anymore. One simple way to do this is to include a Condition that is 
known to always evaluate to true, such as in:<a class="self" href="#rfc.section.10.4.8.p.1">¶</a></p></div><div id="rfc.figure.u.51"><pre class="text">  If: (&lt;urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2&gt;) 
    (Not &lt;DAV:no-lock&gt;)</pre></div><div id="rfc.section.10.4.8.p.2"><p>"DAV:no-lock"
 is known to never represent a current lock token. Lock tokens are 
assigned by the server, following the uniqueness requirements described 
in <a href="#lock-tokens" title="Lock Tokens">Section&nbsp;6.5</a>, 
therefore cannot use the "DAV:" scheme. Thus, by applying "Not" to a 
state token that is known not to be current, the Condition always 
evaluates to true. Consequently, the whole If header will always 
evaluate to true, and the lock token 
urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2 will be submitted in any 
case.<a class="self" href="#rfc.section.10.4.8.p.2">¶</a></p></div></section><section id="n-example---tagged-list-if-header-in-copy"><h4 id="rfc.section.10.4.9"><a href="#rfc.section.10.4.9">10.4.9</a>&nbsp;<a href="#n-example---tagged-list-if-header-in-copy">Example - Tagged List If Header in COPY</a></h4><div id="rfc.figure.u.52"><p>&gt;&gt;Request</p><pre class="text2">  COPY /resource1 HTTP/1.1 
  Host: www.example.com 
  Destination: /resource2 
  If: &lt;/resource1&gt; 
    (&lt;urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2&gt; 
    [W/"A weak ETag"]) (["strong ETag"])</pre></div><div id="rfc.section.10.4.9.p.1"><p>In
 this example, http://www.example.com/resource1 is being copied to 
http://www.example.com/resource2. When the method is first applied to 
http://www.example.com/resource1, resource1 must be in the state 
specified by "(&lt;urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2&gt; 
[W/"A weak ETag"]) (["strong ETag"])". That is, either it must be locked
 with a lock token of "urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2" 
and have a weak entity tag W/"A weak ETag" or it must have a strong 
entity tag "strong ETag".<a class="self" href="#rfc.section.10.4.9.p.1">¶</a></p></div></section><section id="n-example---matching-lock-tokens-with-collection-locks"><h4 id="rfc.section.10.4.10"><a href="#rfc.section.10.4.10">10.4.10</a>&nbsp;<a href="#n-example---matching-lock-tokens-with-collection-locks">Example - Matching Lock Tokens with Collection Locks</a></h4><div id="rfc.figure.u.53"><pre class="text2">  DELETE /specs/rfc2518.txt HTTP/1.1 
  Host: www.example.com 
  If: &lt;http://www.example.com/specs/&gt; 
    (&lt;urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2&gt;)</pre></div><div id="rfc.section.10.4.10.p.1"><p>For
 this example, the lock token must be compared to the identified 
resource, which is the 'specs' collection identified by the URL in the 
tagged list production. If the 'specs' collection is not locked by a 
lock with the specified lock token, the request <em class="bcp14">MUST</em>
 fail. Otherwise, this request could succeed, because the If header 
evaluates to true, and because the lock token for the lock affecting the
 affected resource has been submitted.<a class="self" href="#rfc.section.10.4.10.p.1">¶</a></p></div></section><section id="n-example---matching-etags-on-unmapped-urls"><h4 id="rfc.section.10.4.11"><a href="#rfc.section.10.4.11">10.4.11</a>&nbsp;<a href="#n-example---matching-etags-on-unmapped-urls">Example - Matching ETags on Unmapped URLs</a></h4><div id="rfc.section.10.4.11.p.1"><p>Consider a collection "/specs" that does not contain the member "/specs/rfc2518.doc". In this case, the If header<a class="self" href="#rfc.section.10.4.11.p.1">¶</a></p></div><div id="rfc.figure.u.54"><pre class="text">  If: &lt;/specs/rfc2518.doc&gt; (["4217"])</pre></div><div id="rfc.section.10.4.11.p.2"><p>will
 evaluate to false (the URI isn't mapped, thus the resource identified 
by the URI doesn't have an entity matching the ETag "4217").<a class="self" href="#rfc.section.10.4.11.p.2">¶</a></p></div><div id="rfc.section.10.4.11.p.3"><p>On the other hand, an If header of<a class="self" href="#rfc.section.10.4.11.p.3">¶</a></p></div><div id="rfc.figure.u.55"><pre class="text">  If: &lt;/specs/rfc2518.doc&gt; (Not ["4217"])</pre></div><div id="rfc.section.10.4.11.p.4"><p>will consequently evaluate to true.<a class="self" href="#rfc.section.10.4.11.p.4">¶</a></p></div><div id="rfc.section.10.4.11.p.5"><p>Note that, as defined above in <a href="#if.header.matching.function" title="Matching State Tokens and ETags">Section&nbsp;10.4.4</a>, the same considerations apply to matching state tokens.<a class="self" href="#rfc.section.10.4.11.p.5">¶</a></p></div></section></section><section id="HEADER_Lock-Token"><h3 id="rfc.section.10.5"><a href="#rfc.section.10.5">10.5</a>&nbsp;<a href="#HEADER_Lock-Token">Lock-Token Header</a></h3><div id="rfc.figure.u.56"><pre class="inline">   Lock-Token = "Lock-Token" ":" Coded-URL
</pre></div><div id="rfc.section.10.5.p.1"><p>The Lock-Token request 
header is used with the UNLOCK method to identify the lock to be 
removed. The lock token in the Lock-Token request header <em class="bcp14">MUST</em> identify a lock that contains the resource identified by Request-URI as a member.<a class="self" href="#rfc.section.10.5.p.1">¶</a></p></div><div id="rfc.section.10.5.p.2"><p>The
 Lock-Token response header is used with the LOCK method to indicate the
 lock token created as a result of a successful LOCK request to create a
 new lock.<a class="self" href="#rfc.section.10.5.p.2">¶</a></p></div></section><section id="HEADER_Overwrite"><h3 id="rfc.section.10.6"><a href="#rfc.section.10.6">10.6</a>&nbsp;<a href="#HEADER_Overwrite">Overwrite Header</a></h3><div id="rfc.figure.u.57"><pre class="inline">   Overwrite = "Overwrite" ":" ("T" | "F")
</pre></div><div id="rfc.section.10.6.p.1"><p>The Overwrite request 
header specifies whether the server should overwrite a resource mapped 
to the destination URL during a COPY or MOVE. A value of "F" states that
 the server must not perform the COPY or MOVE operation if the 
destination URL does map to a resource. If the overwrite header is not 
included in a COPY or MOVE request, then the resource <em class="bcp14">MUST</em>
 treat the request as if it has an overwrite header of value "T". While 
the Overwrite header appears to duplicate the functionality of using an 
"If-Match: *" header (see <a href="#RFC2616" id="rfc.xref.RFC2616.27"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>), If-Match applies only to the Request-URI, and not to the Destination of a COPY or MOVE.<a class="self" href="#rfc.section.10.6.p.1">¶</a></p></div><div id="rfc.section.10.6.p.2"><p>If a COPY or MOVE is not performed due to the value of the Overwrite header, the method <em class="bcp14">MUST</em> fail with a 412 (Precondition Failed) status code. The server <em class="bcp14">MUST</em> do authorization checks before checking this or any conditional header.<a class="self" href="#rfc.section.10.6.p.2">¶</a></p></div><div id="rfc.section.10.6.p.3"><p>All DAV-compliant resources <em class="bcp14">MUST</em> support the Overwrite header.<a class="self" href="#rfc.section.10.6.p.3">¶</a></p></div></section><section id="HEADER_Timeout"><h3 id="rfc.section.10.7"><a href="#rfc.section.10.7">10.7</a>&nbsp;<a href="#HEADER_Timeout">Timeout Request Header</a></h3><div id="rfc.figure.u.58"><pre class="inline">   TimeOut = "Timeout" ":" 1#TimeType 
   TimeType = ("Second-" DAVTimeOutVal | "Infinite")  
              ; No LWS allowed within TimeType
   DAVTimeOutVal = 1*DIGIT
</pre></div><div id="rfc.section.10.7.p.1"><p>Clients <em class="bcp14">MAY</em>
 include Timeout request headers in their LOCK requests. However, the 
server is not required to honor or even consider these requests. Clients
 <em class="bcp14">MUST NOT</em> submit a Timeout request header with any method other than a LOCK method.<a class="self" href="#rfc.section.10.7.p.1">¶</a></p></div><div id="rfc.section.10.7.p.2"><p>The
 "Second" TimeType specifies the number of seconds that will elapse 
between granting of the lock at the server, and the automatic removal of
 the lock. The timeout value for TimeType "Second" <em class="bcp14">MUST NOT</em> be greater than 2<sup>32</sup>-1.<a class="self" href="#rfc.section.10.7.p.2">¶</a></p></div><div id="rfc.section.10.7.p.3"><p>See <a href="#lock-timeout" title="Lock Timeout">Section&nbsp;6.6</a> for a description of lock timeout behavior.<a class="self" href="#rfc.section.10.7.p.3">¶</a></p></div></section></section><section id="status.code.extensions.to.http11"><h2 id="rfc.section.11"><a href="#rfc.section.11">11.</a>&nbsp;<a href="#status.code.extensions.to.http11">Status Code Extensions to HTTP/1.1</a></h2><div id="rfc.section.11.p.1"><p>The following status codes are added to those defined in HTTP/1.1 <a href="#RFC2616" id="rfc.xref.RFC2616.28"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.<a class="self" href="#rfc.section.11.p.1">¶</a></p></div><section id="STATUS_207"><h3 id="rfc.section.11.1"><a href="#rfc.section.11.1">11.1</a>&nbsp;<a href="#STATUS_207">207 Multi-Status</a></h3><div id="rfc.section.11.1.p.1"><p>The 207 (Multi-Status) status code provides status for multiple independent operations (see <a href="#multi-status.response" title="Multi-Status Response">Section&nbsp;13</a> for more information).<a class="self" href="#rfc.section.11.1.p.1">¶</a></p></div></section><section id="STATUS_422"><h3 id="rfc.section.11.2"><a href="#rfc.section.11.2">11.2</a>&nbsp;<a href="#STATUS_422">422 Unprocessable Entity</a></h3><div id="rfc.section.11.2.p.1"><p>The
 422 (Unprocessable Entity) status code means the server understands the
 content type of the request entity (hence a 415(Unsupported Media Type)
 status code is inappropriate), and the syntax of the request entity is 
correct (thus a 400 (Bad Request) status code is inappropriate) but was 
unable to process the contained instructions. For example, this error 
condition may occur if an XML request body contains well-formed (i.e., 
syntactically correct), but semantically erroneous, XML instructions.<a class="self" href="#rfc.section.11.2.p.1">¶</a></p></div></section><section id="STATUS_423"><h3 id="rfc.section.11.3"><a href="#rfc.section.11.3">11.3</a>&nbsp;<a href="#STATUS_423">423 Locked</a></h3><div id="rfc.section.11.3.p.1"><p>The 423 (Locked) status code means the source or destination resource of a method is locked. This response <em class="bcp14">SHOULD</em> contain an appropriate precondition or postcondition code, such as 'lock-token-submitted' or 'no-conflicting-lock'.<a class="self" href="#rfc.section.11.3.p.1">¶</a></p></div></section><section id="STATUS_424"><h3 id="rfc.section.11.4"><a href="#rfc.section.11.4">11.4</a>&nbsp;<a href="#STATUS_424">424 Failed Dependency</a></h3><div id="rfc.section.11.4.p.1"><p>The
 424 (Failed Dependency) status code means that the method could not be 
performed on the resource because the requested action depended on 
another action and that action failed. For example, if a command in a 
PROPPATCH method fails, then, at minimum, the rest of the commands will 
also fail with 424 (Failed Dependency).<a class="self" href="#rfc.section.11.4.p.1">¶</a></p></div></section><section id="STATUS_507"><h3 id="rfc.section.11.5"><a href="#rfc.section.11.5">11.5</a>&nbsp;<a href="#STATUS_507">507 Insufficient Storage</a></h3><div id="rfc.section.11.5.p.1"><p>The
 507 (Insufficient Storage) status code means the method could not be 
performed on the resource because the server is unable to store the 
representation needed to successfully complete the request. This 
condition is considered to be temporary. If the request that received 
this status code was the result of a user action, the request <em class="bcp14">MUST NOT</em> be repeated until it is requested by a separate user action.<a class="self" href="#rfc.section.11.5.p.1">¶</a></p></div></section></section><section id="http-status-codes"><h2 id="rfc.section.12"><a href="#rfc.section.12">12.</a>&nbsp;<a href="#http-status-codes">Use of HTTP Status Codes</a></h2><div id="rfc.section.12.p.1"><p>These
 HTTP codes are not redefined, but their use is somewhat extended by 
WebDAV methods and requirements. In general, many HTTP status codes can 
be used in response to any request, not just in cases described in this 
document. Note also that WebDAV servers are known to use 300-level 
redirect responses (and early interoperability tests found clients 
unprepared to see those responses). A 300-level response <em class="bcp14">MUST NOT</em> be used when the server has created a new resource in response to the request.<a class="self" href="#rfc.section.12.p.1">¶</a></p></div><section id="n-412-precondition-failed"><h3 id="rfc.section.12.1"><a href="#rfc.section.12.1">12.1</a>&nbsp;<a href="#n-412-precondition-failed">412 Precondition Failed</a></h3><div id="rfc.section.12.1.p.1"><p>Any
 request can contain a conditional header defined in HTTP (If-Match, 
If-Modified-Since, etc.) or the "If" or "Overwrite" conditional headers 
defined in this specification. If the server evaluates a conditional 
header, and if that condition fails to hold, then this error code <em class="bcp14">MUST</em> be returned. On the other hand, if the client did not include a conditional header in the request, then the server <em class="bcp14">MUST NOT</em> use this status code.<a class="self" href="#rfc.section.12.1.p.1">¶</a></p></div></section><section id="n-414-request-uri-too-long"><h3 id="rfc.section.12.2"><a href="#rfc.section.12.2">12.2</a>&nbsp;<a href="#n-414-request-uri-too-long">414 Request-URI Too Long</a></h3><div id="rfc.section.12.2.p.1"><p>This status code is used in HTTP 1.1 only for Request-URIs, not URIs in other locations.<a class="self" href="#rfc.section.12.2.p.1">¶</a></p></div></section></section><section id="multi-status.response"><h2 id="rfc.section.13"><a href="#rfc.section.13">13.</a>&nbsp;<a href="#multi-status.response">Multi-Status Response</a></h2><div id="rfc.section.13.p.1"><p>A
 Multi-Status response conveys information about multiple resources in 
situations where multiple status codes might be appropriate. The default
 Multi-Status response body is a text/xml or application/xml HTTP entity
 with a 'multistatus' root element. Further elements contain 200, 300, 
400, and 500 series status codes generated during the method invocation.
 100 series status codes <em class="bcp14">SHOULD NOT</em> be recorded in a 'response' XML element.<a class="self" href="#rfc.section.13.p.1">¶</a></p></div><div id="rfc.section.13.p.2"><p>Although
 '207' is used as the overall response status code, the recipient needs 
to consult the contents of the multistatus response body for further 
information about the success or failure of the method execution. The 
response <em class="bcp14">MAY</em> be used in success, partial success and also in failure situations.<a class="self" href="#rfc.section.13.p.2">¶</a></p></div><div id="rfc.section.13.p.3"><p>The
 'multistatus' root element holds zero or more 'response' elements in 
any order, each with information about an individual resource. Each 
'response' element <em class="bcp14">MUST</em> have an 'href' element to identify the resource.<a class="self" href="#rfc.section.13.p.3">¶</a></p></div><div id="rfc.section.13.p.4" class="avoidbreakafter"><p>A Multi-Status response uses one out of two distinct formats for representing the status:<a class="self" href="#rfc.section.13.p.4">¶</a></p></div><div id="rfc.section.13.p.5"><ol><li>A
 'status' element as child of the 'response' element indicates the 
status of the message execution for the identified resource as a whole 
(for instance, see <a href="#DELETE-example" title="Example - DELETE">Section&nbsp;9.6.2</a>).
 Some method definitions provide information about specific status codes
 clients should be prepared to see in a response. However, clients <em class="bcp14">MUST</em> be able to handle other status codes, using the generic rules defined in <a href="https://tools.ietf.org/html/rfc2616#section-10">Section 10</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.29"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.</li><li>For
 PROPFIND and PROPPATCH, the format has been extended using the 
'propstat' element instead of 'status', providing information about 
individual properties of a resource. This format is specific to PROPFIND
 and PROPPATCH, and is described in detail in Sections <a href="#METHOD_PROPFIND" title="PROPFIND Method">9.1</a> and <a href="#METHOD_PROPPATCH" title="PROPPATCH Method">9.2</a>.</li></ol></div><section id="n-response-headers"><h3 id="rfc.section.13.1"><a href="#rfc.section.13.1">13.1</a>&nbsp;<a href="#n-response-headers">Response Headers</a></h3><div id="rfc.section.13.1.p.1"><p>HTTP
 defines the Location header to indicate a preferred URL for the 
resource that was addressed in the Request-URI (e.g., in response to 
successful PUT requests or in redirect responses). However, use of this 
header creates ambiguity when there are URLs in the body of the 
response, as with Multi-Status. Thus, use of the Location header with 
the Multi-Status response is intentionally undefined.<a class="self" href="#rfc.section.13.1.p.1">¶</a></p></div></section><section id="n-handling-redirected-child-resources"><h3 id="rfc.section.13.2"><a href="#rfc.section.13.2">13.2</a>&nbsp;<a href="#n-handling-redirected-child-resources">Handling Redirected Child Resources</a></h3><div id="rfc.section.13.2.p.1"><p>Redirect
 responses (300-303, 305, and 307) defined in HTTP 1.1 normally take a 
Location header to indicate the new URI for the single resource 
redirected from the Request-URI. Multi-Status responses contain many 
resource addresses, but the original definition in <a href="#RFC2518" id="rfc.xref.RFC2518.3"><cite title="HTTP Extensions for Distributed Authoring -- WEBDAV">[RFC2518]</cite></a>
 did not have any place for the server to provide the new URI for 
redirected resources. This specification does define a 'location' 
element for this information (see <a href="#ELEMENT_location" title="location XML Element">Section&nbsp;14.9</a>). Servers <em class="bcp14">MUST</em> use this new element with redirect responses in Multi-Status.<a class="self" href="#rfc.section.13.2.p.1">¶</a></p></div><div id="rfc.section.13.2.p.2"><p>Clients encountering redirected resources in Multi-Status <em class="bcp14">MUST NOT</em> rely on the 'location' element being present with a new URI. If the element is not present, the client <em class="bcp14">MAY</em>
 reissue the request to the individual redirected resource, because the 
response to that request can be redirected with a Location header 
containing the new URI.<a class="self" href="#rfc.section.13.2.p.2">¶</a></p></div></section><section id="n-internal-status-codes"><h3 id="rfc.section.13.3"><a href="#rfc.section.13.3">13.3</a>&nbsp;<a href="#n-internal-status-codes">Internal Status Codes</a></h3><div id="rfc.section.13.3.p.1"><p>Sections <a href="#PROPPATCH-status" title="Status Codes for Use in 'propstat' Element">9.2.1</a>, <a href="#PROPFIND-multistatus" title="Status Codes for Use in 'propstat' Element">9.1.2</a>, <a href="#delete-collections" title="DELETE for Collections">9.6.1</a>, <a href="#copy.for.collections" title="COPY for Collections">9.8.3</a>, and <a href="#move-collections" title="MOVE for Collections">9.9.2</a>
 define various status codes used in Multi-Status responses. This 
specification does not define the meaning of other status codes that 
could appear in these responses.<a class="self" href="#rfc.section.13.3.p.1">¶</a></p></div></section></section><section id="xml.element.definitions"><h2 id="rfc.section.14"><a href="#rfc.section.14">14.</a>&nbsp;<a href="#xml.element.definitions">XML Element Definitions</a></h2><div id="rfc.section.14.p.1"><p>In this section, the final line of each section gives the element type declaration using the format defined in <a href="#REC-XML" id="rfc.xref.REC-XML.4"><cite title="Extensible Markup Language (XML) 1.0 (Fourth Edition)">[REC-XML]</cite></a>.
 The "Value" field, where present, specifies further restrictions on the
 allowable contents of the XML element using BNF (i.e., to further 
restrict the values of a PCDATA element). Note that all of the elements 
defined here may be extended according to the rules defined in <a href="#xml-extensibility" title="XML Extensibility in DAV">Section&nbsp;17</a>. All elements defined here are in the "DAV:" namespace.<a class="self" href="#rfc.section.14.p.1">¶</a></p></div><section id="ELEMENT_activelock"><h3 id="rfc.section.14.1"><a href="#rfc.section.14.1">14.1</a>&nbsp;<a href="#ELEMENT_activelock">activelock XML Element</a></h3><div id="rfc.section.14.1.p.1"><dl><dt>Name: </dt><dd>activelock</dd><dt>Purpose: </dt><dd>Describes a lock on a resource.</dd></dl></div><div id="rfc.figure.u.59"><pre class="inline">&lt;!ELEMENT <a href="#ELEMENT_activelock" class="smpl">activelock</a> (<a href="#ELEMENT_lockscope" class="smpl">lockscope</a>, <a href="#ELEMENT_locktype" class="smpl">locktype</a>, <a href="#ELEMENT_depth" class="smpl">depth</a>, <a href="#ELEMENT_owner" class="smpl">owner</a>?, <a href="#ELEMENT_timeout" class="smpl">timeout</a>?, 
          <a href="#ELEMENT_locktoken" class="smpl">locktoken</a>?, <a href="#ELEMENT_lockroot" class="smpl">lockroot</a>)&gt;</pre></div></section><section id="ELEMENT_allprop"><h3 id="rfc.section.14.2"><a href="#rfc.section.14.2">14.2</a>&nbsp;<a href="#ELEMENT_allprop">allprop XML Element</a></h3><div id="rfc.section.14.2.p.1"><dl><dt>Name: </dt><dd>allprop</dd><dt>Purpose: </dt><dd>Specifies
 that all names and values of dead properties and the live properties 
defined by this document existing on the resource are to be returned.</dd></dl></div><div id="rfc.figure.u.60"><pre class="inline">&lt;!ELEMENT <a href="#ELEMENT_allprop" class="smpl">allprop</a> EMPTY &gt;</pre></div></section><section id="ELEMENT_collection"><h3 id="rfc.section.14.3"><a href="#rfc.section.14.3">14.3</a>&nbsp;<a href="#ELEMENT_collection">collection XML Element</a></h3><div id="rfc.section.14.3.p.1"><dl><dt>Name: </dt><dd>collection</dd><dt>Purpose: </dt><dd>Identifies the associated resource as a collection. The DAV:resourcetype property of a collection resource <em class="bcp14">MUST</em> contain this element. It is normally empty but extensions may add sub-elements.</dd></dl></div><div id="rfc.figure.u.61"><pre class="inline">&lt;!ELEMENT <a href="#ELEMENT_collection" class="smpl">collection</a> EMPTY &gt; </pre></div></section><section id="ELEMENT_depth"><h3 id="rfc.section.14.4"><a href="#rfc.section.14.4">14.4</a>&nbsp;<a href="#ELEMENT_depth">depth XML Element</a></h3><div id="rfc.section.14.4.p.1"><dl><dt>Name: </dt><dd>depth</dd><dt>Purpose: </dt><dd>Used for representing depth values in XML content (e.g., in lock information).</dd><dt>Value: </dt><dd>"0" | "1" | "infinity"</dd></dl></div><div id="rfc.figure.u.62"><pre class="inline">&lt;!ELEMENT <a href="#ELEMENT_depth" class="smpl">depth</a> (#PCDATA) &gt;</pre></div></section><section id="ELEMENT_error"><h3 id="rfc.section.14.5"><a href="#rfc.section.14.5">14.5</a>&nbsp;<a href="#ELEMENT_error">error XML Element</a></h3><div id="rfc.section.14.5.p.1"><dl><dt>Name: </dt><dd>error</dd><dt>Purpose: </dt><dd>Error
 responses, particularly 403 Forbidden and 409 Conflict, sometimes need 
more information to indicate what went wrong. In these cases, servers <em class="bcp14">MAY</em>
 return an XML response body with a document element of 'error', 
containing child elements identifying particular condition codes.</dd><dt>Description: </dt><dd>Contains at least one XML element, and <em class="bcp14">MUST NOT</em>
 contain text or mixed content. Any element that is a child of the 
'error' element is considered to be a precondition or postcondition 
code. Unrecognized elements <em class="bcp14">MUST</em> be ignored.</dd></dl></div><div id="rfc.figure.u.63"><pre class="inline">&lt;!ELEMENT <a href="#ELEMENT_error" class="smpl">error</a> ANY &gt;</pre></div></section><section id="ELEMENT_exclusive"><h3 id="rfc.section.14.6"><a href="#rfc.section.14.6">14.6</a>&nbsp;<a href="#ELEMENT_exclusive">exclusive XML Element</a></h3><div id="rfc.section.14.6.p.1"><dl><dt>Name: </dt><dd>exclusive</dd><dt>Purpose: </dt><dd>Specifies an exclusive lock.</dd></dl></div><div id="rfc.figure.u.64"><pre class="inline">&lt;!ELEMENT <a href="#ELEMENT_exclusive" class="smpl">exclusive</a> EMPTY &gt;</pre></div></section><section id="ELEMENT_href"><h3 id="rfc.section.14.7"><a href="#rfc.section.14.7">14.7</a>&nbsp;<a href="#ELEMENT_href">href XML Element</a></h3><div id="rfc.section.14.7.p.1"><dl><dt>Name: </dt><dd>href</dd><dt>Purpose: </dt><dd><em class="bcp14">MUST</em> contain a URI or a relative reference.</dd><dt>Description: </dt><dd>There
 may be limits on the value of 'href' depending on the context of its 
use. Refer to the specification text where 'href' is used to see what 
limitations apply in each case.</dd><dt>Value: </dt><dd>Simple-ref</dd></dl></div><div id="rfc.figure.u.65"><pre class="inline">&lt;!ELEMENT <a href="#ELEMENT_href" class="smpl">href</a> (#PCDATA)&gt;</pre></div></section><section id="ELEMENT_include"><h3 id="rfc.section.14.8"><a href="#rfc.section.14.8">14.8</a>&nbsp;<a href="#ELEMENT_include">include XML Element</a></h3><div id="rfc.section.14.8.p.1"><dl><dt>Name: </dt><dd>include</dd><dt>Purpose: </dt><dd>Any
 child element represents the name of a property to be included in the 
PROPFIND response. All elements inside an 'include' XML element <em class="bcp14">MUST</em>
 define properties related to the resource, although possible property 
names are in no way limited to those property names defined in this 
document or other standards. This element <em class="bcp14">MUST NOT</em> contain text or mixed content.</dd></dl></div><div id="rfc.figure.u.66"><pre class="inline">&lt;!ELEMENT <a href="#ELEMENT_include" class="smpl">include</a> ANY &gt;</pre></div></section><section id="ELEMENT_location"><h3 id="rfc.section.14.9"><a href="#rfc.section.14.9">14.9</a>&nbsp;<a href="#ELEMENT_location">location XML Element</a></h3><div id="rfc.section.14.9.p.1"><dl><dt>Name: </dt><dd>location</dd><dt>Purpose: </dt><dd>HTTP defines the "Location" header (see <a href="#RFC2616" id="rfc.xref.RFC2616.30"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="https://tools.ietf.org/html/rfc2616#section-14.30">Section 14.30</a>)
 for use with some status codes (such as 201 and the 300 series codes). 
When these codes are used inside a 'multistatus' element, the 'location'
 element can be used to provide the accompanying Location header value.</dd><dt>Description: </dt><dd>Contains a single href element with the same value that would be used in a Location header.</dd></dl><span id="rfc.figure.u.67"><pre class="inline">&lt;!ELEMENT <a href="#ELEMENT_location" class="smpl">location</a> (<a href="#ELEMENT_href" class="smpl">href</a>)&gt;</pre></span></div></section><section id="ELEMENT_lockentry"><h3 id="rfc.section.14.10"><a href="#rfc.section.14.10">14.10</a>&nbsp;<a href="#ELEMENT_lockentry">lockentry XML Element</a></h3><div id="rfc.section.14.10.p.1"><dl><dt>Name: </dt><dd>lockentry</dd><dt>Purpose: </dt><dd>Defines the types of locks that can be used with the resource.</dd></dl></div><div id="rfc.figure.u.68"><pre class="inline">&lt;!ELEMENT <a href="#ELEMENT_lockentry" class="smpl">lockentry</a> (<a href="#ELEMENT_lockscope" class="smpl">lockscope</a>, <a href="#ELEMENT_locktype" class="smpl">locktype</a>) &gt;</pre></div></section><section id="ELEMENT_lockinfo"><h3 id="rfc.section.14.11"><a href="#rfc.section.14.11">14.11</a>&nbsp;<a href="#ELEMENT_lockinfo">lockinfo XML Element</a></h3><div id="rfc.section.14.11.p.1"><dl><dt>Name: </dt><dd>lockinfo</dd><dt>Purpose: </dt><dd>The 'lockinfo' XML element is used with a LOCK method to specify the type of lock the client wishes to have created.</dd></dl></div><div id="rfc.figure.u.69"><pre class="inline">&lt;!ELEMENT <a href="#ELEMENT_lockinfo" class="smpl">lockinfo</a> (<a href="#ELEMENT_lockscope" class="smpl">lockscope</a>, <a href="#ELEMENT_locktype" class="smpl">locktype</a>, <a href="#ELEMENT_owner" class="smpl">owner</a>?)  &gt;</pre></div></section><section id="ELEMENT_lockroot"><h3 id="rfc.section.14.12"><a href="#rfc.section.14.12">14.12</a>&nbsp;<a href="#ELEMENT_lockroot">lockroot XML Element</a></h3><div id="rfc.section.14.12.p.1"><dl><dt>Name: </dt><dd>lockroot</dd><dt>Purpose: </dt><dd>Contains the root URL of the lock, which is the URL through which the resource was addressed in the LOCK request.</dd><dt>Description: </dt><dd>The href element contains the root of the lock. The server <em class="bcp14">SHOULD</em> include this in all DAV:lockdiscovery property values and the response to LOCK requests.</dd></dl></div><div id="rfc.figure.u.70"><pre class="inline">&lt;!ELEMENT <a href="#ELEMENT_lockroot" class="smpl">lockroot</a> (<a href="#ELEMENT_href" class="smpl">href</a>) &gt;</pre></div></section><section id="ELEMENT_lockscope"><h3 id="rfc.section.14.13"><a href="#rfc.section.14.13">14.13</a>&nbsp;<a href="#ELEMENT_lockscope">lockscope XML Element</a></h3><div id="rfc.section.14.13.p.1"><dl><dt>Name: </dt><dd>lockscope</dd><dt>Purpose: </dt><dd>Specifies whether a lock is an exclusive lock, or a shared lock.</dd></dl></div><div id="rfc.figure.u.71"><pre class="inline">&lt;!ELEMENT <a href="#ELEMENT_lockscope" class="smpl">lockscope</a> (<a href="#ELEMENT_exclusive" class="smpl">exclusive</a> | <a href="#ELEMENT_shared" class="smpl">shared</a>) &gt;</pre></div></section><section id="ELEMENT_locktoken"><h3 id="rfc.section.14.14"><a href="#rfc.section.14.14">14.14</a>&nbsp;<a href="#ELEMENT_locktoken">locktoken XML Element</a></h3><div id="rfc.section.14.14.p.1"><dl><dt>Name: </dt><dd>locktoken</dd><dt>Purpose: </dt><dd>The lock token associated with a lock.</dd><dt>Description: </dt><dd>The href contains a single lock token URI, which refers to the lock.</dd></dl></div><div id="rfc.figure.u.72"><pre class="inline">&lt;!ELEMENT <a href="#ELEMENT_locktoken" class="smpl">locktoken</a> (<a href="#ELEMENT_href" class="smpl">href</a>) &gt;</pre></div></section><section id="ELEMENT_locktype"><h3 id="rfc.section.14.15"><a href="#rfc.section.14.15">14.15</a>&nbsp;<a href="#ELEMENT_locktype">locktype XML Element</a></h3><div id="rfc.section.14.15.p.1"><dl><dt>Name: </dt><dd>locktype</dd><dt>Purpose: </dt><dd>Specifies the access type of a lock. At present, this specification only defines one lock type, the write lock.</dd></dl></div><div id="rfc.figure.u.73"><pre class="inline">&lt;!ELEMENT <a href="#ELEMENT_locktype" class="smpl">locktype</a> (<a href="#ELEMENT_write" class="smpl">write</a>) &gt;</pre></div></section><section id="ELEMENT_multistatus"><h3 id="rfc.section.14.16"><a href="#rfc.section.14.16">14.16</a>&nbsp;<a href="#ELEMENT_multistatus">multistatus XML Element</a></h3><div id="rfc.section.14.16.p.1"><dl><dt>Name: </dt><dd>multistatus</dd><dt>Purpose: </dt><dd>Contains multiple response messages.</dd><dt>Description: </dt><dd>The
 'responsedescription' element at the top level is used to provide a 
general message describing the overarching nature of the response. If 
this value is available, an application may use it instead of presenting
 the individual response descriptions contained within the responses.</dd></dl></div><div id="rfc.figure.u.74"><pre class="inline">&lt;!ELEMENT <a href="#ELEMENT_multistatus" class="smpl">multistatus</a> (<a href="#ELEMENT_response" class="smpl">response</a>*, <a href="#ELEMENT_responsedescription" class="smpl">responsedescription</a>?)  &gt;</pre></div></section><section id="ELEMENT_owner"><h3 id="rfc.section.14.17"><a href="#rfc.section.14.17">14.17</a>&nbsp;<a href="#ELEMENT_owner">owner XML Element</a></h3><div id="rfc.section.14.17.p.1"><dl><dt>Name: </dt><dd>owner</dd><dt>Purpose: </dt><dd>Holds client-supplied information about the creator of a lock.</dd><dt>Description: </dt><dd>Allows
 a client to provide information sufficient for either directly 
contacting a principal (such as a telephone number or Email URI), or for
 discovering the principal (such as the URL of a homepage) who created a
 lock. The value provided <em class="bcp14">MUST</em> be treated as a dead property in terms of XML Information Item preservation. The server <em class="bcp14">MUST NOT</em>
 alter the value unless the owner value provided by the client is empty.
 For a certain amount of interoperability between different client 
implementations, if clients have URI-formatted contact information for 
the lock creator suitable for user display, then clients <em class="bcp14">SHOULD</em> put those URIs in 'href' child elements of the 'owner' element.</dd><dt>Extensibility: </dt><dd><em class="bcp14">MAY</em> be extended with child elements, mixed content, text content or attributes.</dd></dl></div><div id="rfc.figure.u.75"><pre class="inline">&lt;!ELEMENT <a href="#ELEMENT_owner" class="smpl">owner</a> ANY &gt;</pre></div></section><section id="ELEMENT_prop"><h3 id="rfc.section.14.18"><a href="#rfc.section.14.18">14.18</a>&nbsp;<a href="#ELEMENT_prop">prop XML Element</a></h3><div id="rfc.section.14.18.p.1"><dl><dt>Name: </dt><dd>prop</dd><dt>Purpose: </dt><dd>Contains properties related to a resource.</dd><dt>Description: </dt><dd>A generic container for properties defined on resources. All elements inside a 'prop' XML element <em class="bcp14">MUST</em>
 define properties related to the resource, although possible property 
names are in no way limited to those property names defined in this 
document or other standards. This element <em class="bcp14">MUST NOT</em> contain text or mixed content.</dd></dl></div><div id="rfc.figure.u.76"><pre class="inline">&lt;!ELEMENT <a href="#ELEMENT_prop" class="smpl">prop</a> ANY &gt;</pre></div></section><section id="ELEMENT_propertyupdate"><h3 id="rfc.section.14.19"><a href="#rfc.section.14.19">14.19</a>&nbsp;<a href="#ELEMENT_propertyupdate">propertyupdate XML Element</a></h3><div id="rfc.section.14.19.p.1"><dl><dt>Name: </dt><dd>propertyupdate</dd><dt>Purpose: </dt><dd>Contains a request to alter the properties on a resource.</dd><dt>Description: </dt><dd>This XML element is a container for the information required to modify the properties on the resource.</dd></dl></div><div id="rfc.figure.u.77"><pre class="inline">&lt;!ELEMENT <a href="#ELEMENT_propertyupdate" class="smpl">propertyupdate</a> (<a href="#ELEMENT_remove" class="smpl">remove</a> | <a href="#ELEMENT_set" class="smpl">set</a>)+ &gt;</pre></div></section><section id="ELEMENT_propfind"><h3 id="rfc.section.14.20"><a href="#rfc.section.14.20">14.20</a>&nbsp;<a href="#ELEMENT_propfind">propfind XML Element</a></h3><div id="rfc.section.14.20.p.1"><dl><dt>Name: </dt><dd>propfind</dd><dt>Purpose: </dt><dd>Specifies
 the properties to be returned from a PROPFIND method. Four special 
elements are specified for use with 'propfind': 'prop', 'allprop', 
'include', and 'propname'. If 'prop' is used inside 'propfind', it <em class="bcp14">MUST NOT</em> contain property values.</dd></dl></div><div id="rfc.figure.u.78"><pre class="inline">&lt;!ELEMENT <a href="#ELEMENT_propfind" class="smpl">propfind</a> ( <a href="#ELEMENT_propname" class="smpl">propname</a> | (<a href="#ELEMENT_allprop" class="smpl">allprop</a>, <a href="#ELEMENT_include" class="smpl">include</a>?) | <a href="#ELEMENT_prop" class="smpl">prop</a> ) &gt;</pre></div></section><section id="ELEMENT_propname"><h3 id="rfc.section.14.21"><a href="#rfc.section.14.21">14.21</a>&nbsp;<a href="#ELEMENT_propname">propname XML Element</a></h3><div id="rfc.section.14.21.p.1"><dl><dt>Name: </dt><dd>propname</dd><dt>Purpose: </dt><dd>Specifies that only a list of property names on the resource is to be returned.</dd></dl></div><div id="rfc.figure.u.79"><pre class="inline">&lt;!ELEMENT <a href="#ELEMENT_propname" class="smpl">propname</a> EMPTY &gt;</pre></div></section><section id="ELEMENT_propstat"><h3 id="rfc.section.14.22"><a href="#rfc.section.14.22">14.22</a>&nbsp;<a href="#ELEMENT_propstat">propstat XML Element</a></h3><div id="rfc.section.14.22.p.1"><dl><dt>Name: </dt><dd>propstat</dd><dt>Purpose: </dt><dd>Groups together a prop and status element that is associated with a particular 'href' element.</dd><dt>Description: </dt><dd>The propstat XML element <em class="bcp14">MUST</em> contain one prop XML element and one status XML element. The contents of the prop XML element <em class="bcp14">MUST</em>
 only list the names of properties to which the result in the status 
element applies. The optional precondition/postcondition element and 
'responsedescription' text also apply to the properties named in 'prop'.</dd></dl></div><div id="rfc.figure.u.80"><pre class="inline">&lt;!ELEMENT <a href="#ELEMENT_propstat" class="smpl">propstat</a> (<a href="#ELEMENT_prop" class="smpl">prop</a>, <a href="#ELEMENT_status" class="smpl">status</a>, <a href="#ELEMENT_error" class="smpl">error</a>?, <a href="#ELEMENT_responsedescription" class="smpl">responsedescription</a>?) &gt;</pre></div></section><section id="ELEMENT_remove"><h3 id="rfc.section.14.23"><a href="#rfc.section.14.23">14.23</a>&nbsp;<a href="#ELEMENT_remove">remove XML Element</a></h3><div id="rfc.section.14.23.p.1"><dl><dt>Name: </dt><dd>remove</dd><dt>Purpose: </dt><dd>Lists the properties to be removed from a resource.</dd><dt>Description: </dt><dd>Remove
 instructs that the properties specified in prop should be removed. 
Specifying the removal of a property that does not exist is not an 
error. All the XML elements in a 'prop' XML element inside of a 'remove'
 XML element <em class="bcp14">MUST</em> be empty, as only the names of properties to be removed are required.</dd></dl></div><div id="rfc.figure.u.81"><pre class="inline">&lt;!ELEMENT <a href="#ELEMENT_remove" class="smpl">remove</a> (<a href="#ELEMENT_prop" class="smpl">prop</a>) &gt;</pre></div></section><section id="ELEMENT_response"><h3 id="rfc.section.14.24"><a href="#rfc.section.14.24">14.24</a>&nbsp;<a href="#ELEMENT_response">response XML Element</a></h3><div id="rfc.section.14.24.p.1"><dl><dt>Name: </dt><dd>response</dd><dt>Purpose: </dt><dd>Holds a single response describing the effect of a method on resource and/or its properties.</dd><dt>Description: </dt><dd>The
 'href' element contains an HTTP URL pointing to a WebDAV resource when 
used in the 'response' container. A particular 'href' value <em class="bcp14">MUST NOT</em>
 appear more than once as the child of a 'response' XML element under a 
'multistatus' XML element. This requirement is necessary in order to 
keep processing costs for a response to linear time. Essentially, this 
prevents having to search in order to group together all the responses 
by 'href'. There are, however, no requirements regarding ordering based 
on 'href' values. The optional precondition/postcondition element and 
'responsedescription' text can provide additional information about this
 resource relative to the request or result.</dd></dl></div><div id="rfc.figure.u.82"><pre class="inline">&lt;!ELEMENT <a href="#ELEMENT_response" class="smpl">response</a> (<a href="#ELEMENT_href" class="smpl">href</a>, ((<a href="#ELEMENT_href" class="smpl">href</a>*, <a href="#ELEMENT_status" class="smpl">status</a>)|(<a href="#ELEMENT_propstat" class="smpl">propstat</a>+)), 
                    <a href="#ELEMENT_error" class="smpl">error</a>?, <a href="#ELEMENT_responsedescription" class="smpl">responsedescription</a>? , <a href="#ELEMENT_location" class="smpl">location</a>?) &gt;</pre></div></section><section id="ELEMENT_responsedescription"><h3 id="rfc.section.14.25"><a href="#rfc.section.14.25">14.25</a>&nbsp;<a href="#ELEMENT_responsedescription">responsedescription XML Element</a></h3><div id="rfc.section.14.25.p.1"><dl><dt>Name: </dt><dd>responsedescription</dd><dt>Purpose: </dt><dd>Contains information about a status response within a Multi-Status.</dd><dt>Description: </dt><dd>Provides information suitable to be presented to a user.</dd></dl></div><div id="rfc.figure.u.83"><pre class="inline">&lt;!ELEMENT <a href="#ELEMENT_responsedescription" class="smpl">responsedescription</a> (#PCDATA) &gt;</pre></div></section><section id="ELEMENT_set"><h3 id="rfc.section.14.26"><a href="#rfc.section.14.26">14.26</a>&nbsp;<a href="#ELEMENT_set">set XML Element</a></h3><div id="rfc.section.14.26.p.1"><dl><dt>Name: </dt><dd>set</dd><dt>Purpose: </dt><dd>Lists the property values to be set for a resource.</dd><dt>Description: </dt><dd>The 'set' element <em class="bcp14">MUST</em> contain only a 'prop' element. The elements contained by the 'prop' element inside the 'set' element <em class="bcp14">MUST</em>
 specify the name and value of properties that are set on the resource 
identified by Request-URI. If a property already exists, then its value 
is replaced. Language tagging information appearing in the scope of the 
'prop' element (in the "xml:lang" attribute, if present) <em class="bcp14">MUST</em> be persistently stored along with the property, and <em class="bcp14">MUST</em> be subsequently retrievable using PROPFIND.</dd></dl></div><div id="rfc.figure.u.84"><pre class="inline">&lt;!ELEMENT <a href="#ELEMENT_set" class="smpl">set</a> (<a href="#ELEMENT_prop" class="smpl">prop</a>) &gt;</pre></div></section><section id="ELEMENT_shared"><h3 id="rfc.section.14.27"><a href="#rfc.section.14.27">14.27</a>&nbsp;<a href="#ELEMENT_shared">shared XML Element</a></h3><div id="rfc.section.14.27.p.1"><dl><dt>Name: </dt><dd>shared</dd><dt>Purpose: </dt><dd>Specifies a shared lock.</dd></dl></div><div id="rfc.figure.u.85"><pre class="inline">&lt;!ELEMENT <a href="#ELEMENT_shared" class="smpl">shared</a> EMPTY &gt;</pre></div></section><section id="ELEMENT_status"><h3 id="rfc.section.14.28"><a href="#rfc.section.14.28">14.28</a>&nbsp;<a href="#ELEMENT_status">status XML Element</a></h3><div id="rfc.section.14.28.p.1"><dl><dt>Name: </dt><dd>status</dd><dt>Purpose: </dt><dd>Holds a single HTTP status-line.</dd><dt>Value: </dt><dd>status-line (defined in <a href="https://tools.ietf.org/html/rfc2616#section-6.1">Section 6.1</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.31"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>)</dd></dl></div><div id="rfc.figure.u.86"><pre class="inline">&lt;!ELEMENT <a href="#ELEMENT_status" class="smpl">status</a> (#PCDATA) &gt;</pre></div></section><section id="ELEMENT_timeout"><h3 id="rfc.section.14.29"><a href="#rfc.section.14.29">14.29</a>&nbsp;<a href="#ELEMENT_timeout">timeout XML Element</a></h3><div id="rfc.section.14.29.p.1"><dl><dt>Name: </dt><dd>timeout</dd><dt>Purpose: </dt><dd>The number of seconds remaining before a lock expires.</dd><dt>Value: </dt><dd>TimeType (defined in <a href="#HEADER_Timeout" title="Timeout Request Header">Section&nbsp;10.7</a>)</dd></dl></div><div id="rfc.figure.u.87"><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_timeout" class="smpl">timeout</a> (#PCDATA) &gt;</pre></div></section><section id="ELEMENT_write"><h3 id="rfc.section.14.30"><a href="#rfc.section.14.30">14.30</a>&nbsp;<a href="#ELEMENT_write">write XML Element</a></h3><div id="rfc.section.14.30.p.1"><dl><dt>Name: </dt><dd>write</dd><dt>Purpose: </dt><dd>Specifies a write lock.</dd></dl></div><div id="rfc.figure.u.88"><pre class="inline">&lt;!ELEMENT <a href="#ELEMENT_write" class="smpl">write</a> EMPTY &gt;</pre></div></section></section><section id="dav.properties"><h2 id="rfc.section.15"><a href="#rfc.section.15">15.</a>&nbsp;<a href="#dav.properties">DAV Properties</a></h2><div id="rfc.section.15.p.1"><p>For
 DAV properties, the name of the property is also the same as the name 
of the XML element that contains its value. In the section below, the 
final line of each section gives the element type declaration using the 
format defined in <a href="#REC-XML" id="rfc.xref.REC-XML.5"><cite title="Extensible Markup Language (XML) 1.0 (Fourth Edition)">[REC-XML]</cite></a>.
 The "Value" field, where present, specifies further restrictions on the
 allowable contents of the XML element using BNF (i.e., to further 
restrict the values of a PCDATA element).<a class="self" href="#rfc.section.15.p.1">¶</a></p></div><div id="rfc.section.15.p.2"><p>A
 protected property is one that cannot be changed with a PROPPATCH 
request. There may be other requests that would result in a change to a 
protected property (as when a LOCK request affects the value of 
DAV:lockdiscovery). Note that a given property could be protected on one
 type of resource, but not protected on another type of resource.<a class="self" href="#rfc.section.15.p.2">¶</a></p></div><div id="rfc.section.15.p.3"><p>A
 computed property is one with a value defined in terms of a computation
 (based on the content and other properties of that resource, or even of
 some other resource). A computed property is always a protected 
property.<a class="self" href="#rfc.section.15.p.3">¶</a></p></div><div id="rfc.section.15.p.4"><p>COPY and MOVE behavior refers to local COPY and MOVE operations.<a class="self" href="#rfc.section.15.p.4">¶</a></p></div><div id="rfc.section.15.p.5"><p>For properties defined based on HTTP GET response headers (DAV:get*), the header value could include LWS as defined in <a href="#RFC2616" id="rfc.xref.RFC2616.32"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="https://tools.ietf.org/html/rfc2616#section-4.2">Section 4.2</a>. Server implementors <em class="bcp14">SHOULD</em> strip LWS from these values before using as WebDAV property values.<a class="self" href="#rfc.section.15.p.5">¶</a></p></div><section id="PROPERTY_creationdate"><h3 id="rfc.section.15.1"><a href="#rfc.section.15.1">15.1</a>&nbsp;<a href="#PROPERTY_creationdate">creationdate Property</a></h3><div id="rfc.section.15.1.p.1"><dl><dt>Name: </dt><dd>creationdate</dd><dt>Purpose: </dt><dd>Records the time and date the resource was created.</dd><dt>Value: </dt><dd>date-time (defined in <a href="#RFC3339" id="rfc.xref.RFC3339.1"><cite title="Date and Time on the Internet: Timestamps">[RFC3339]</cite></a>, see the ABNF in <a href="https://tools.ietf.org/html/rfc3339#section-5.6" id="rfc.xref.RFC3339.2">Section 5.6</a>.)</dd><dt>Protected: </dt><dd><em class="bcp14">MAY</em>
 be protected. Some servers allow DAV:creationdate to be changed to 
reflect the time the document was created if that is more meaningful to 
the user (rather than the time it was uploaded). Thus, clients <em class="bcp14">SHOULD NOT</em> use this property in synchronization logic (use DAV:getetag instead).</dd><dt>COPY/MOVE behavior: </dt><dd>This property value <em class="bcp14">SHOULD</em>
 be kept during a MOVE operation, but is normally re-initialized when a 
resource is created with a COPY. It should not be set in a COPY.</dd><dt>Description: </dt><dd>The DAV:creationdate property <em class="bcp14">SHOULD</em>
 be defined on all DAV compliant resources. If present, it contains a 
timestamp of the moment when the resource was created. Servers that are 
incapable of persistently recording the creation date <em class="bcp14">SHOULD</em> instead leave it undefined (i.e. report "Not Found").</dd></dl></div><div id="rfc.figure.u.89"><pre class="inline">&lt;!ELEMENT <a href="#PROPERTY_creationdate" class="smpl">creationdate</a> (#PCDATA) &gt;</pre></div></section><section id="PROPERTY_displayname"><h3 id="rfc.section.15.2"><a href="#rfc.section.15.2">15.2</a>&nbsp;<a href="#PROPERTY_displayname">displayname Property</a></h3><div id="rfc.section.15.2.p.1"><dl><dt>Name: </dt><dd>displayname</dd><dt>Purpose: </dt><dd>Provides a name for the resource that is suitable for presentation to a user.</dd><dt>Value: </dt><dd>Any text.</dd><dt>Protected: </dt><dd><em class="bcp14">SHOULD NOT</em> be protected. Note that servers implementing <a href="#RFC2518" id="rfc.xref.RFC2518.4"><cite title="HTTP Extensions for Distributed Authoring -- WEBDAV">[RFC2518]</cite></a> might have made this a protected property as this is a new requirement.</dd><dt>COPY/MOVE behavior: </dt><dd>This property value <em class="bcp14">SHOULD</em> be preserved in COPY and MOVE operations.</dd><dt>Description: </dt><dd>Contains
 a description of the resource that is suitable for presentation to a 
user. This property is defined on the resource, and hence <em class="bcp14">SHOULD</em>
 have the same value independent of the Request-URI used to retrieve it 
(thus, computing this property based on the Request-URI is deprecated). 
While generic clients might display the property value to end users, 
client UI designers must understand that the method for identifying 
resources is still the URL. Changes to DAV:displayname do not issue 
moves or copies to the server, but simply change a piece of meta-data on
 the individual resource. Two resources can have the same 
DAV:displayname value even within the same collection.</dd></dl></div><div id="rfc.figure.u.90"><pre class="inline">&lt;!ELEMENT <a href="#PROPERTY_displayname" class="smpl">displayname</a> (#PCDATA) &gt;</pre></div></section><section id="PROPERTY_getcontentlanguage"><h3 id="rfc.section.15.3"><a href="#rfc.section.15.3">15.3</a>&nbsp;<a href="#PROPERTY_getcontentlanguage">getcontentlanguage Property</a></h3><div id="rfc.section.15.3.p.1"><dl><dt>Name: </dt><dd>getcontentlanguage</dd><dt>Purpose: </dt><dd>Contains the Content-Language header value (from <a href="https://tools.ietf.org/html/rfc2616#section-14.12">Section 14.12</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.33"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>) as it would be returned by a GET without accept headers.</dd><dt>Value: </dt><dd>language-tag (language-tag is defined in <a href="https://tools.ietf.org/html/rfc2616#section-3.10">Section 3.10</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.34"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>)</dd><dt>Protected: </dt><dd><em class="bcp14">SHOULD NOT</em> be protected, so that clients can reset the language. Note that servers implementing <a href="#RFC2518" id="rfc.xref.RFC2518.5"><cite title="HTTP Extensions for Distributed Authoring -- WEBDAV">[RFC2518]</cite></a> might have made this a protected property as this is a new requirement.</dd><dt>COPY/MOVE behavior: </dt><dd>This property value <em class="bcp14">SHOULD</em> be preserved in COPY and MOVE operations.</dd><dt>Description: </dt><dd>The DAV:getcontentlanguage property <em class="bcp14">MUST</em> be defined on any DAV-compliant resource that returns the Content-Language header on a GET.</dd></dl></div><div id="rfc.figure.u.91"><pre class="inline">&lt;!ELEMENT <a href="#PROPERTY_getcontentlanguage" class="smpl">getcontentlanguage</a> (#PCDATA) &gt;</pre></div></section><section id="PROPERTY_getcontentlength"><h3 id="rfc.section.15.4"><a href="#rfc.section.15.4">15.4</a>&nbsp;<a href="#PROPERTY_getcontentlength">getcontentlength Property</a></h3><div id="rfc.section.15.4.p.1"><dl><dt>Name: </dt><dd>getcontentlength</dd><dt>Purpose: </dt><dd>Contains the Content-Length header returned by a GET without accept headers.</dd><dt>Value: </dt><dd>See <a href="https://tools.ietf.org/html/rfc2616#section-14.13">Section 14.13</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.35"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.</dd><dt>Protected: </dt><dd>This property is computed, therefore protected.</dd><dt>Description: </dt><dd>The DAV:getcontentlength property <em class="bcp14">MUST</em> be defined on any DAV-compliant resource that returns the Content-Length header in response to a GET.</dd><dt>COPY/MOVE behavior: </dt><dd>This property value is dependent on the size of the destination resource, not the value of the property on the source resource.</dd></dl></div><div id="rfc.figure.u.92"><pre class="inline">&lt;!ELEMENT <a href="#PROPERTY_getcontentlength" class="smpl">getcontentlength</a> (#PCDATA) &gt;</pre></div></section><section id="PROPERTY_getcontenttype"><h3 id="rfc.section.15.5"><a href="#rfc.section.15.5">15.5</a>&nbsp;<a href="#PROPERTY_getcontenttype">getcontenttype Property</a></h3><div id="rfc.section.15.5.p.1"><dl><dt>Name: </dt><dd>getcontenttype</dd><dt>Purpose: </dt><dd>Contains the Content-Type header value (from <a href="https://tools.ietf.org/html/rfc2616#section-14.17">Section 14.17</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.36"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>) as it would be returned by a GET without accept headers.</dd><dt>Value: </dt><dd>media-type (defined in <a href="https://tools.ietf.org/html/rfc2616#section-3.7">Section 3.7</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.37"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>)</dd><dt>Protected: </dt><dd>Potentially protected if the server prefers to assign content types on its own (see also discussion in <a href="#put-resources" title="PUT for Non-Collection Resources">Section&nbsp;9.7.1</a>).</dd><dt>COPY/MOVE behavior: </dt><dd>This property value <em class="bcp14">SHOULD</em> be preserved in COPY and MOVE operations.</dd><dt>Description: </dt><dd>This property <em class="bcp14">MUST</em> be defined on any DAV-compliant resource that returns the Content-Type header in response to a GET.</dd></dl></div><div id="rfc.figure.u.93"><pre class="inline">&lt;!ELEMENT <a href="#PROPERTY_getcontenttype" class="smpl">getcontenttype</a> (#PCDATA) &gt;</pre></div></section><section id="PROPERTY_getetag"><h3 id="rfc.section.15.6"><a href="#rfc.section.15.6">15.6</a>&nbsp;<a href="#PROPERTY_getetag">getetag Property</a></h3><div id="rfc.section.15.6.p.1"><dl><dt>Name: </dt><dd>getetag</dd><dt>Purpose: </dt><dd>Contains the ETag header value (from <a href="https://tools.ietf.org/html/rfc2616#section-14.19">Section 14.19</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.38"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>) as it would be returned by a GET without accept headers.</dd><dt>Value: </dt><dd>entity-tag (defined in <a href="https://tools.ietf.org/html/rfc2616#section-3.11">Section 3.11</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.39"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>)</dd><dt>Protected: </dt><dd><em class="bcp14">MUST</em> be protected because this value is created and controlled by the server.</dd><dt>COPY/MOVE behavior: </dt><dd>This
 property value is dependent on the final state of the destination 
resource, not the value of the property on the source resource. Also 
note the considerations in <a href="#cache-control" title="Impact of Namespace Operations on Cache Validators">Section&nbsp;8.8</a>.</dd><dt>Description: </dt><dd>The getetag property <em class="bcp14">MUST</em> be defined on any DAV-compliant resource that returns the Etag header. Refer to <a href="https://tools.ietf.org/html/rfc2616#section-3.11" id="rfc.xref.RFC2616.40">Section 3.11</a> of RFC 2616 for a complete definition of the semantics of an ETag, and to <a href="#etag" title="ETag">Section&nbsp;8.6</a> for a discussion of ETags in WebDAV.</dd></dl></div><div id="rfc.figure.u.94"><pre class="inline">&lt;!ELEMENT <a href="#PROPERTY_getetag" class="smpl">getetag</a> (#PCDATA) &gt;</pre></div></section><section id="PROPERTY_getlastmodified"><h3 id="rfc.section.15.7"><a href="#rfc.section.15.7">15.7</a>&nbsp;<a href="#PROPERTY_getlastmodified">getlastmodified Property</a></h3><div id="rfc.section.15.7.p.1"><dl><dt>Name: </dt><dd>getlastmodified</dd><dt>Purpose: </dt><dd>Contains the Last-Modified header value (from <a href="https://tools.ietf.org/html/rfc2616#section-14.29">Section 14.29</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.41"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>) as it would be returned by a GET method without accept headers.</dd><dt>Value: </dt><dd>rfc1123-date (defined in <a href="https://tools.ietf.org/html/rfc2616#section-3.3.1">Section 3.3.1</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.42"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>)</dd><dt>Protected: </dt><dd><em class="bcp14">SHOULD</em>
 be protected because some clients may rely on the value for appropriate
 caching behavior, or on the value of the Last-Modified header to which 
this property is linked.</dd><dt>COPY/MOVE behavior: </dt><dd>This 
property value is dependent on the last modified date of the destination
 resource, not the value of the property on the source resource. Note 
that some server implementations use the file system date modified value
 for the DAV:getlastmodified value, and this can be preserved in a MOVE 
even when the HTTP Last-Modified value <em class="bcp14">SHOULD</em> change. Note that since <a href="#RFC2616" id="rfc.xref.RFC2616.43"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>
 requires clients to use ETags where provided, a server implementing 
ETags can count on clients using a much better mechanism than 
modification dates for offline synchronization or cache control. Also 
note the considerations in <a href="#cache-control" title="Impact of Namespace Operations on Cache Validators">Section&nbsp;8.8</a>.</dd><dt>Description: </dt><dd>The last-modified date on a resource <em class="bcp14">SHOULD</em> only reflect changes in the body (the GET responses) of the resource. A change in a property only <em class="bcp14">SHOULD NOT</em> cause the last-modified date to change, because clients <em class="bcp14">MAY</em> rely on the last-modified date to know when to overwrite the existing body. The DAV:getlastmodified property <em class="bcp14">MUST</em> be defined on any DAV-compliant resource that returns the Last-Modified header in response to a GET.</dd></dl></div><div id="rfc.figure.u.95"><pre class="inline">&lt;!ELEMENT <a href="#PROPERTY_getlastmodified" class="smpl">getlastmodified</a> (#PCDATA) &gt;</pre></div></section><section id="PROPERTY_lockdiscovery"><h3 id="rfc.section.15.8"><a href="#rfc.section.15.8">15.8</a>&nbsp;<a href="#PROPERTY_lockdiscovery">lockdiscovery Property</a></h3><div id="rfc.section.15.8.p.1"><dl><dt>Name: </dt><dd>lockdiscovery</dd><dt>Purpose: </dt><dd>Describes the active locks on a resource</dd><dt>Protected: </dt><dd><em class="bcp14">MUST</em> be protected. Clients change the list of locks through LOCK and UNLOCK, not through PROPPATCH.</dd><dt>COPY/MOVE behavior: </dt><dd>The
 value of this property depends on the lock state of the destination, 
not on the locks of the source resource. Recall that locks are not moved
 in a MOVE operation.</dd><dt>Description: </dt><dd>Returns a listing of
 who has a lock, what type of lock he has, the timeout type and the time
 remaining on the timeout, and the associated lock token. Owner 
information <em class="bcp14">MAY</em> be omitted if it is considered 
sensitive. If there are no locks, but the server supports locks, the 
property will be present but contain zero 'activelock' elements. If 
there are one or more locks, an 'activelock' element appears for each 
lock on the resource. This property is NOT lockable with respect to 
write locks (<a href="#write-lock" title="Write Lock">Section&nbsp;7</a>).</dd></dl></div><div id="rfc.figure.u.96"><pre class="inline">&lt;!ELEMENT <a href="#PROPERTY_lockdiscovery" class="smpl">lockdiscovery</a> (<a href="#ELEMENT_activelock" class="smpl">activelock</a>)* &gt;</pre></div><section id="n-example---retrieving-dav-lockdiscovery"><h4 id="rfc.section.15.8.1"><a href="#rfc.section.15.8.1">15.8.1</a>&nbsp;<a href="#n-example---retrieving-dav-lockdiscovery">Example - Retrieving DAV:lockdiscovery</a></h4><div id="rfc.figure.u.97"><p>&gt;&gt;Request</p><pre class="text2">  PROPFIND /container/ HTTP/1.1 
  Host: www.example.com 
  Content-Length: xxxx 
  Content-Type: application/xml; charset="utf-8" 
  
  &lt;?xml version="1.0" encoding="utf-8" ?&gt; 
  &lt;D:propfind xmlns:D='DAV:'&gt; 
    &lt;D:prop&gt;&lt;D:lockdiscovery/&gt;&lt;/D:prop&gt; 
  &lt;/D:propfind&gt; 
</pre></div><div id="rfc.figure.u.98"><p>&gt;&gt;Response</p><pre class="text">  HTTP/1.1 207 Multi-Status 
  Content-Type: application/xml; charset="utf-8" 
  Content-Length: xxxx 
  
  &lt;?xml version="1.0" encoding="utf-8" ?&gt; 
  &lt;D:multistatus xmlns:D='DAV:'&gt; 
    &lt;D:response&gt; 
      &lt;D:href&gt;http://www.example.com/container/&lt;/D:href&gt; 
      &lt;D:propstat&gt; 
        &lt;D:prop&gt; 
          &lt;D:lockdiscovery&gt; 
           &lt;D:activelock&gt; 
            &lt;D:locktype&gt;&lt;D:write/&gt;&lt;/D:locktype&gt; 
            &lt;D:lockscope&gt;&lt;D:exclusive/&gt;&lt;/D:lockscope&gt; 
            &lt;D:depth&gt;0&lt;/D:depth&gt; 
            &lt;D:owner&gt;Jane Smith&lt;/D:owner&gt; 
            &lt;D:timeout&gt;Infinite&lt;/D:timeout&gt; 
            &lt;D:locktoken&gt; 
              &lt;D:href
          &gt;urn:uuid:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76&lt;/D:href&gt;
            &lt;/D:locktoken&gt; 
            &lt;D:lockroot&gt; 
              &lt;D:href&gt;http://www.example.com/container/&lt;/D:href&gt; 
            &lt;/D:lockroot&gt; 
           &lt;/D:activelock&gt; 
          &lt;/D:lockdiscovery&gt; 
        &lt;/D:prop&gt; 
        &lt;D:status&gt;HTTP/1.1 200 OK&lt;/D:status&gt; 
      &lt;/D:propstat&gt; 
    &lt;/D:response&gt; 
  &lt;/D:multistatus&gt; 
</pre><p>This resource has a single exclusive write lock on it, with an infinite timeout.</p></div></section></section><section id="PROPERTY_resourcetype"><h3 id="rfc.section.15.9"><a href="#rfc.section.15.9">15.9</a>&nbsp;<a href="#PROPERTY_resourcetype">resourcetype Property</a></h3><div id="rfc.section.15.9.p.1"><dl><dt>Name: </dt><dd>resourcetype</dd><dt>Purpose: </dt><dd>Specifies the nature of the resource.</dd><dt>Protected: </dt><dd><em class="bcp14">SHOULD</em> be protected. Resource type is generally decided through the operation creating the resource (MKCOL vs PUT), not by PROPPATCH.</dd><dt>COPY/MOVE behavior: </dt><dd>Generally a COPY/MOVE of a resource results in the same type of resource at the destination.</dd><dt>Description: </dt><dd><em class="bcp14">MUST</em>
 be defined on all DAV-compliant resources. Each child element 
identifies a specific type the resource belongs to, such as 
'collection', which is the only resource type defined by this 
specification (see <a href="#ELEMENT_collection" title="collection XML Element">Section&nbsp;14.3</a>).
 If the element contains the 'collection' child element plus additional 
unrecognized elements, it should generally be treated as a collection. 
If the element contains no recognized child elements, it should be 
treated as a non-collection resource. The default value is empty. This 
element <em class="bcp14">MUST NOT</em> contain text or mixed content. Any custom child element is considered to be an identifier for a resource type.</dd></dl></div><div id="rfc.figure.u.99"><p>Example: (fictional example to show extensibility)</p><pre class="text">    &lt;x:resourcetype xmlns:x="DAV:"&gt; 
        &lt;x:collection/&gt; 
        &lt;f:search-results xmlns:f="http://www.example.com/ns"/&gt; 
    &lt;/x:resourcetype&gt; 
</pre></div></section><section id="PROPERTY_supportedlock"><h3 id="rfc.section.15.10"><a href="#rfc.section.15.10">15.10</a>&nbsp;<a href="#PROPERTY_supportedlock">supportedlock Property</a></h3><div id="rfc.section.15.10.p.1"><dl><dt>Name: </dt><dd>supportedlock</dd><dt>Purpose: </dt><dd>To provide a listing of the lock capabilities supported by the resource.</dd><dt>Protected: </dt><dd><em class="bcp14">MUST</em> be protected. Servers, not clients, determine what lock mechanisms are supported.</dd><dt>COPY/MOVE behavior: </dt><dd>This
 property value is dependent on the kind of locks supported at the 
destination, not on the value of the property at the source resource. 
Servers attempting to COPY to a destination should not attempt to set 
this property at the destination.</dd><dt>Description: </dt><dd>Returns a
 listing of the combinations of scope and access types that may be 
specified in a lock request on the resource. Note that the actual 
contents are themselves controlled by access controls, so a server is 
not required to provide information the client is not authorized to see.
 This property is NOT lockable with respect to write locks (<a href="#write-lock" title="Write Lock">Section&nbsp;7</a>).</dd></dl></div><div id="rfc.figure.u.100"><pre class="inline">&lt;!ELEMENT <a href="#PROPERTY_supportedlock" class="smpl">supportedlock</a> (<a href="#ELEMENT_lockentry" class="smpl">lockentry</a>)* &gt;
</pre></div><section id="n-example---retrieving-dav-supportedlock"><h4 id="rfc.section.15.10.1"><a href="#rfc.section.15.10.1">15.10.1</a>&nbsp;<a href="#n-example---retrieving-dav-supportedlock">Example - Retrieving DAV:supportedlock</a></h4><div id="rfc.figure.u.101"><p>&gt;&gt;Request</p><pre class="text2">  PROPFIND /container/ HTTP/1.1 
  Host: www.example.com 
  Content-Length: xxxx 
  Content-Type: application/xml; charset="utf-8" 
  
  &lt;?xml version="1.0" encoding="utf-8" ?&gt; 
  &lt;D:propfind xmlns:D="DAV:"&gt; 
    &lt;D:prop&gt;&lt;D:supportedlock/&gt;&lt;/D:prop&gt; 
  &lt;/D:propfind&gt; 
</pre></div><div id="rfc.figure.u.102"><p>&gt;&gt;Response</p><pre class="text">  HTTP/1.1 207 Multi-Status 
  Content-Type: application/xml; charset="utf-8" 
  Content-Length: xxxx 
  
  &lt;?xml version="1.0" encoding="utf-8" ?&gt; 
  &lt;D:multistatus xmlns:D="DAV:"&gt; 
    &lt;D:response&gt; 
      &lt;D:href&gt;http://www.example.com/container/&lt;/D:href&gt; 
      &lt;D:propstat&gt; 
        &lt;D:prop&gt; 
          &lt;D:supportedlock&gt; 
            &lt;D:lockentry&gt; 
              &lt;D:lockscope&gt;&lt;D:exclusive/&gt;&lt;/D:lockscope&gt; 
              &lt;D:locktype&gt;&lt;D:write/&gt;&lt;/D:locktype&gt; 
            &lt;/D:lockentry&gt; 
            &lt;D:lockentry&gt; 
              &lt;D:lockscope&gt;&lt;D:shared/&gt;&lt;/D:lockscope&gt; 
              &lt;D:locktype&gt;&lt;D:write/&gt;&lt;/D:locktype&gt; 
            &lt;/D:lockentry&gt; 
          &lt;/D:supportedlock&gt; 
        &lt;/D:prop&gt; 
        &lt;D:status&gt;HTTP/1.1 200 OK&lt;/D:status&gt; 
      &lt;/D:propstat&gt; 
    &lt;/D:response&gt; 
  &lt;/D:multistatus&gt; 
</pre></div></section></section></section><section id="precondition.postcondition.xml.elements"><h2 id="rfc.section.16"><a href="#rfc.section.16">16.</a>&nbsp;<a href="#precondition.postcondition.xml.elements">Precondition/Postcondition XML Elements</a></h2><div id="rfc.section.16.p.1"><p>As introduced in <a href="#including.error.reponse.bodies" title="Including Error Response Bodies">Section&nbsp;8.7</a>,
 extra information on error conditions can be included in the body of 
many status responses. This section makes requirements on the use of the
 error body mechanism and introduces a number of precondition and 
postcondition codes.<a class="self" href="#rfc.section.16.p.1">¶</a></p></div><div id="rfc.section.16.p.2"><p><span id="rfc.iref.p.4"></span> <span id="rfc.iref.p.5"></span> A "<dfn>precondition</dfn>" of a method describes the state of the server that must be true for that method to be performed. A "<dfn>postcondition</dfn>" of a method describes the state of the server that must be true after that method has been completed.<a class="self" href="#rfc.section.16.p.2">¶</a></p></div><div id="rfc.section.16.p.3"><p>Each
 precondition and postcondition has a unique XML element associated with
 it. In a 207 Multi-Status response, the XML element <em class="bcp14">MUST</em>
 appear inside an 'error' element in the appropriate 'propstat or 
'response' element depending on whether the condition applies to one or 
more properties or to the resource as a whole. In all other error 
responses where this specification's 'error' body is used, the 
precondition/postcondition XML element <em class="bcp14">MUST</em> be 
returned as the child of a top-level 'error' element in the response 
body, unless otherwise negotiated by the request, along with an 
appropriate response status. The most common response status codes are 
403 (Forbidden) if the request should not be repeated because it will 
always fail, and 409 (Conflict) if it is expected that the user might be
 able to resolve the conflict and resubmit the request. The 'error' 
element <em class="bcp14">MAY</em> contain child elements with specific error information and <em class="bcp14">MAY</em> be extended with any custom child elements.<a class="self" href="#rfc.section.16.p.3">¶</a></p></div><div id="rfc.section.16.p.4"><p>This
 mechanism does not take the place of using a correct numeric status 
code as defined here or in HTTP, because the client must always be able 
to take a reasonable course of action based only on the numeric code. 
However, it does remove the need to define new numeric codes. The new 
machine-readable codes used for this purpose are XML elements classified
 as preconditions and postconditions, so naturally, any group defining a
 new condition code can use their own namespace. As always, the "DAV:" 
namespace is reserved for use by IETF-chartered WebDAV working groups.<a class="self" href="#rfc.section.16.p.4">¶</a></p></div><div id="rfc.section.16.p.5"><p>A server supporting this specification <em class="bcp14">SHOULD</em>
 use the XML error whenever a precondition or postcondition defined in 
this document is violated. For error conditions not specified in this 
document, the server <em class="bcp14">MAY</em> simply choose an appropriate numeric status and leave the response body blank. However, a server <em class="bcp14">MAY</em>
 instead use a custom condition code and other supporting text, because 
even when clients do not automatically recognize condition codes, they 
can be quite useful in interoperability testing and debugging.<a class="self" href="#rfc.section.16.p.5">¶</a></p></div><div id="rfc.section.16.p.6"><p>Example - Response with precondition code<a class="self" href="#rfc.section.16.p.6">¶</a></p></div><div id="rfc.figure.u.103"><p>&gt;&gt;Response</p><pre class="text"> HTTP/1.1 423 Locked
 Content-Type: application/xml; charset="utf-8"
 Content-Length: xxxx

 &lt;?xml version="1.0" encoding="utf-8" ?&gt;
 &lt;D:error xmlns:D="DAV:"&gt;
   &lt;D:lock-token-submitted&gt;
     &lt;D:href&gt;/workspace/webdav/&lt;/D:href&gt;
   &lt;/D:lock-token-submitted&gt;
 &lt;/D:error&gt;
</pre><p>In this example, a client unaware of a depth-infinity lock on 
the parent collection "/workspace/webdav/" attempted to modify the 
collection member "/workspace/webdav/proposal.doc".</p></div><div id="rfc.section.16.p.7"><p>Some other useful preconditions and postconditions have been defined in other specifications extending WebDAV, such as <a href="#RFC3744" id="rfc.xref.RFC3744.3"><cite title="Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol">[RFC3744]</cite></a> (see particularly <a href="https://tools.ietf.org/html/rfc3744#section-7.1.1" id="rfc.xref.RFC3744.4">Section 7.1.1</a>), <a href="#RFC3253" id="rfc.xref.RFC3253.6"><cite title="Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)">[RFC3253]</cite></a>, and <a href="#RFC3648" id="rfc.xref.RFC3648.1"><cite title="Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol">[RFC3648]</cite></a>.<a class="self" href="#rfc.section.16.p.7">¶</a></p></div><div id="rfc.section.16.p.8"><p>All
 these elements are in the "DAV:" namespace. If not specified otherwise,
 the content for each condition's XML element is defined to be empty.<a class="self" href="#rfc.section.16.p.8">¶</a></p></div><div id="rfc.section.16.p.9"><dl><dt>Name:</dt><dd>lock-token-matches-request-uri</dd><dt>Use with:</dt><dd>409 Conflict</dd><dt>Purpose:</dt><dd>(precondition)
 -- A request may include a Lock-Token header to identify a lock for the
 UNLOCK method. However, if the Request-URI does not fall within the 
scope of the lock identified by the token, the server <em class="bcp14">SHOULD</em>
 use this error. The lock may have a scope that does not include the 
Request-URI, or the lock could have disappeared, or the token may be 
invalid.</dd></dl></div><div id="rfc.section.16.p.10"><dl><dt>Name:</dt><dd>lock-token-submitted (precondition)</dd><dt>Use with:</dt><dd>423 Locked</dd><dt>Purpose:</dt><dd>The request could not succeed because a lock token should have been submitted. This element, if present, <em class="bcp14">MUST</em>
 contain at least one URL of a locked resource that prevented the 
request. In cases of MOVE, COPY, and DELETE where collection locks are 
involved, it can be difficult for the client to find out which locked 
resource made the request fail -- but the server is only responsible for
 returning one such locked resource. The server <em class="bcp14">MAY</em> return every locked resource that prevented the request from succeeding if it knows them all.</dd></dl></div><div id="rfc.figure.u.104"><pre class="inline">&lt;!ELEMENT lock-token-submitted (href+) &gt;</pre></div><div id="rfc.section.16.p.11"><dl><dt>Name:</dt><dd>no-conflicting-lock (precondition)</dd><dt>Use with:</dt><dd>Typically 423 Locked</dd><dt>Purpose:</dt><dd>A
 LOCK request failed due the presence of an already existing conflicting
 lock. Note that a lock can be in conflict although the resource to 
which the request was directed is only indirectly locked. In this case, 
the precondition code can be used to inform the client about the 
resource that is the root of the conflicting lock, avoiding a separate 
lookup of the "lockdiscovery" property.</dd></dl></div><div id="rfc.figure.u.105"><pre class="inline">&lt;!ELEMENT no-conflicting-lock (href)* &gt;</pre></div><div id="rfc.section.16.p.12"><dl><dt>Name:</dt><dd>no-external-entities</dd><dt>Use with:</dt><dd>403 Forbidden</dd><dt>Purpose:</dt><dd>(precondition) -- If the server rejects a client request because the request body contains an external entity, the server <em class="bcp14">SHOULD</em> use this error.</dd></dl></div><div id="rfc.section.16.p.13"><dl><dt>Name:</dt><dd>preserved-live-properties</dd><dt>Use with:</dt><dd>409 Conflict</dd><dt>Purpose:</dt><dd>(postcondition)
 -- The server received an otherwise-valid MOVE or COPY request, but 
cannot maintain the live properties with the same behavior at the 
destination. It may be that the server only supports some live 
properties in some parts of the repository, or simply has an internal 
error.</dd></dl></div><div id="rfc.section.16.p.14"><dl><dt>Name:</dt><dd>propfind-finite-depth</dd><dt>Use with:</dt><dd>403 Forbidden</dd><dt>Purpose:</dt><dd>(precondition) -- This server does not allow infinite-depth PROPFIND requests on collections.</dd></dl></div><div id="rfc.section.16.p.15"><dl><dt>Name:</dt><dd>cannot-modify-protected-property</dd><dt>Use with:</dt><dd>403 Forbidden</dd><dt>Purpose:</dt><dd>(precondition) -- The client attempted to set a protected property in a PROPPATCH (such as DAV:getetag). See also <a href="#RFC3253" id="rfc.xref.RFC3253.7"><cite title="Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)">[RFC3253]</cite></a>, <a href="https://tools.ietf.org/html/rfc3253#section-3.12">Section 3.12</a>.</dd></dl></div></section><section id="xml-extensibility"><h2 id="rfc.section.17"><a href="#rfc.section.17">17.</a>&nbsp;<a href="#xml-extensibility">XML Extensibility in DAV</a></h2><div id="rfc.section.17.p.1"><p>The XML namespace extension (<a href="#REC-XML-NAMES" id="rfc.xref.REC-XML-NAMES.2"><cite title="Namespaces in XML 1.0 (Second Edition)">[REC-XML-NAMES]</cite></a>)
 is used in this specification in order to allow for new XML elements to
 be added without fear of colliding with other element names. Although 
WebDAV request and response bodies can be extended by arbitrary XML 
elements, which can be ignored by the message recipient, an XML element 
in the "DAV:" namespace <em class="bcp14">SHOULD NOT</em> be used in the
 request or response body unless that XML element is explicitly defined 
in an IETF RFC reviewed by a WebDAV working group.<a class="self" href="#rfc.section.17.p.1">¶</a></p></div><div id="rfc.section.17.p.2"><p>For
 WebDAV to be both extensible and backwards-compatible, both clients and
 servers need to know how to behave when unexpected or unrecognized 
command extensions are received. For XML processing, this means that 
clients and servers <em class="bcp14">MUST</em> process received XML 
documents as if unexpected elements and attributes (and all children of 
unrecognized elements) were not there. An unexpected element or 
attribute includes one that may be used in another context but is not 
expected here. Ignoring such items for purposes of processing can of 
course be consistent with logging all information or presenting for 
debugging.<a class="self" href="#rfc.section.17.p.2">¶</a></p></div><div id="rfc.section.17.p.3"><p>This restriction also applies to the processing, by clients, of DAV property values where unexpected XML elements <em class="bcp14">SHOULD</em> be ignored unless the property's schema declares otherwise.<a class="self" href="#rfc.section.17.p.3">¶</a></p></div><div id="rfc.section.17.p.4"><p>This restriction does not apply to setting dead DAV properties on the server where the server <em class="bcp14">MUST</em> record all XML elements.<a class="self" href="#rfc.section.17.p.4">¶</a></p></div><div id="rfc.section.17.p.5"><p>Additionally,
 this restriction does not apply to the use of XML where XML happens to 
be the content type of the entity body, for example, when used as the 
body of a PUT.<a class="self" href="#rfc.section.17.p.5">¶</a></p></div><div id="rfc.section.17.p.6"><p>Processing instructions in XML <em class="bcp14">SHOULD</em> be ignored by recipients. Thus, specifications extending WebDAV <em class="bcp14">SHOULD NOT</em> use processing instructions to define normative behavior.<a class="self" href="#rfc.section.17.p.6">¶</a></p></div><div id="rfc.section.17.p.7" class="avoidbreakafter"><p>XML
 DTD fragments are included for all the XML elements defined in this 
specification. However, correct XML will not be valid according to any 
DTD due to namespace usage and extension rules. In particular:<a class="self" href="#rfc.section.17.p.7">¶</a></p></div><div id="rfc.section.17.p.8"><ul><li>Elements (from this specification) are in the "DAV:" namespace,</li><li>Element ordering is irrelevant unless otherwise stated,</li><li>Extension attributes <em class="bcp14">MAY</em> be added,</li><li>For
 element type definitions of "ANY", the normative text definition for 
that element defines what can be in it and what that means.</li><li>For element type definitions of "#PCDATA", extension elements <em class="bcp14">MUST NOT</em> be added.</li><li>For other element type definitions, including "EMPTY", extension elements <em class="bcp14">MAY</em> be added.</li></ul></div><div id="rfc.section.17.p.9"><p>Note that this means that elements containing elements cannot be extended to contain text, and vice versa.<a class="self" href="#rfc.section.17.p.9">¶</a></p></div><div id="rfc.section.17.p.10"><p>With DTD validation relaxed by the rules above, the constraints described by the DTD fragments are normative (see for example <a href="#xml-appendix" title="Notes on Processing XML Elements">Appendix&nbsp;A</a>). A recipient of a WebDAV message with an XML body <em class="bcp14">MUST NOT</em> validate the XML document according to any hard-coded or dynamically-declared DTD.<a class="self" href="#rfc.section.17.p.10">¶</a></p></div><div id="rfc.section.17.p.11"><p>Note
 that this section describes backwards-compatible extensibility rules. 
There might also be times when an extension is designed not to be 
backwards-compatible, for example, defining an extension that reuses an 
XML element defined in this document but omitting one of the child 
elements required by the DTDs in this specification.<a class="self" href="#rfc.section.17.p.11">¶</a></p></div></section><section id="dav.compliance.classes"><h2 id="rfc.section.18"><a href="#rfc.section.18">18.</a>&nbsp;<a href="#dav.compliance.classes">DAV Compliance Classes</a></h2><div id="rfc.section.18.p.1"><p>A
 DAV-compliant resource can advertise several classes of compliance. A 
client can discover the compliance classes of a resource by executing 
OPTIONS on the resource and examining the "DAV" header which is 
returned. Note particularly that resources, rather than servers, are 
spoken of as being compliant. That is because theoretically some 
resources on a server could support different feature sets. For example,
 a server could have a sub-repository where an advanced feature like 
versioning was supported, even if that feature was not supported on all 
sub-repositories.<a class="self" href="#rfc.section.18.p.1">¶</a></p></div><div id="rfc.section.18.p.2"><p>Since this document describes extensions to the HTTP/1.1 protocol, minimally all DAV-compliant resources, clients, and proxies <em class="bcp14">MUST</em> be compliant with <a href="#RFC2616" id="rfc.xref.RFC2616.44"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.<a class="self" href="#rfc.section.18.p.2">¶</a></p></div><div id="rfc.section.18.p.3"><p>A resource that is class 2 or class 3 compliant must also be class 1 compliant.<a class="self" href="#rfc.section.18.p.3">¶</a></p></div><section id="n-class-1"><h3 id="rfc.section.18.1"><a href="#rfc.section.18.1">18.1</a>&nbsp;<a href="#n-class-1">Class 1</a></h3><div id="rfc.section.18.1.p.1"><p>A class 1 compliant resource <em class="bcp14">MUST</em> meet all "MUST" requirements in all sections of this document.<a class="self" href="#rfc.section.18.1.p.1">¶</a></p></div><div id="rfc.section.18.1.p.2"><p>Class 1 compliant resources <em class="bcp14">MUST</em> return, at minimum, the value "1" in the DAV header on all responses to the OPTIONS method.<a class="self" href="#rfc.section.18.1.p.2">¶</a></p></div></section><section id="n-class-2"><h3 id="rfc.section.18.2"><a href="#rfc.section.18.2">18.2</a>&nbsp;<a href="#n-class-2">Class 2</a></h3><div id="rfc.section.18.2.p.1"><p>A class 2 compliant resource <em class="bcp14">MUST</em>
 meet all class 1 requirements and support the LOCK method, the 
DAV:supportedlock property, the DAV:lockdiscovery property, the Time-Out
 response header and the Lock-Token request header. A class 2 compliant 
resource <em class="bcp14">SHOULD</em> also support the Timeout request header and the 'owner' XML element.<a class="self" href="#rfc.section.18.2.p.1">¶</a></p></div><div id="rfc.section.18.2.p.2"><p>Class 2 compliant resources <em class="bcp14">MUST</em> return, at minimum, the values "1" and "2" in the DAV header on all responses to the OPTIONS method.<a class="self" href="#rfc.section.18.2.p.2">¶</a></p></div></section><section id="compliance-class-3"><h3 id="rfc.section.18.3"><a href="#rfc.section.18.3">18.3</a>&nbsp;<a href="#compliance-class-3">Class 3</a></h3><div id="rfc.section.18.3.p.1"><p>A resource can explicitly advertise its support for the revisions to <a href="#RFC2518" id="rfc.xref.RFC2518.6"><cite title="HTTP Extensions for Distributed Authoring -- WEBDAV">[RFC2518]</cite></a> made in this document. Class 1 <em class="bcp14">MUST</em> be supported as well. Class 2 <em class="bcp14">MAY</em>
 be supported. Advertising class 3 support in addition to class 1 and 2 
means that the server supports all the requirements in this 
specification. Advertising class 3 and class 1 support, but not class 2,
 means that the server supports all the requirements in this 
specification except possibly those that involve locking support.<a class="self" href="#rfc.section.18.3.p.1">¶</a></p></div><div id="rfc.figure.u.106"><p>Example:</p><pre class="text">         DAV: 1, 3
</pre></div></section></section><section id="internationalization.considerations"><h2 id="rfc.section.19"><a href="#rfc.section.19">19.</a>&nbsp;<a href="#internationalization.considerations">Internationalization Considerations</a></h2><div id="rfc.section.19.p.1"><p>In the realm of internationalization, this specification complies with the IETF Character Set Policy <a href="#RFC2277" id="rfc.xref.RFC2277.1"><cite title="IETF Policy on Character Sets and Languages">[RFC2277]</cite></a>.
 In this specification, human-readable fields can be found either in the
 value of a property, or in an error message returned in a response 
entity body. In both cases, the human-readable content is encoded using 
XML, which has explicit provisions for character set tagging and 
encoding, and requires that XML processors read XML elements encoded, at
 minimum, using the UTF-8 <a href="#RFC3629" id="rfc.xref.RFC3629.1"><cite title="UTF-8, a transformation format of ISO 10646">[RFC3629]</cite></a> and UTF-16 <a href="#RFC2781" id="rfc.xref.RFC2781.1"><cite title="UTF-16, an encoding of ISO 10646">[RFC2781]</cite></a>
 encodings of the ISO 10646 multilingual plane. XML examples in this 
specification demonstrate use of the charset parameter of the 
Content-Type header (defined in <a href="#RFC3023" id="rfc.xref.RFC3023.1"><cite title="XML Media Types">[RFC3023]</cite></a>), as well as XML charset declarations.<a class="self" href="#rfc.section.19.p.1">¶</a></p></div><div id="rfc.section.19.p.2"><p>XML
 also provides a language tagging capability for specifying the language
 of the contents of a particular XML element. The "xml:lang" attribute 
appears on an XML element to identify the language of its content and 
attributes. See <a href="#REC-XML" id="rfc.xref.REC-XML.6"><cite title="Extensible Markup Language (XML) 1.0 (Fourth Edition)">[REC-XML]</cite></a> for definitions of values and scoping.<a class="self" href="#rfc.section.19.p.2">¶</a></p></div><div id="rfc.section.19.p.3"><p>WebDAV applications <em class="bcp14">MUST</em>
 support the character set tagging, character set encoding, and the 
language tagging functionality of the XML specification. Implementors of
 WebDAV applications are strongly encouraged to read "XML Media Types" <a href="#RFC3023" id="rfc.xref.RFC3023.2"><cite title="XML Media Types">[RFC3023]</cite></a>
 for instruction on which MIME media type to use for XML transport, and 
on use of the charset parameter of the Content-Type header.<a class="self" href="#rfc.section.19.p.3">¶</a></p></div><div id="rfc.section.19.p.4"><p>Names
 used within this specification fall into four categories: names of 
protocol elements such as methods and headers, names of XML elements, 
names of properties, and names of conditions. Naming of protocol 
elements follows the precedent of HTTP, using English names encoded in 
US-ASCII for methods and headers. Since these protocol elements are not 
visible to users, and are simply long token identifiers, they do not 
need to support multiple languages. Similarly, the names of XML elements
 used in this specification are not visible to the user and hence do not
 need to support multiple languages.<a class="self" href="#rfc.section.19.p.4">¶</a></p></div><div id="rfc.section.19.p.5"><p>WebDAV
 property names are qualified XML names (pairs of XML namespace name and
 local name). Although some applications (e.g., a generic property 
viewer) will display property names directly to their users, it is 
expected that the typical application will use a fixed set of 
properties, and will provide a mapping from the property name and 
namespace to a human-readable field when displaying the property name to
 a user. It is only in the case where the set of properties is not known
 ahead of time that an application need display a property name to a 
user. We recommend that applications provide human-readable property 
names wherever feasible.<a class="self" href="#rfc.section.19.p.5">¶</a></p></div><div id="rfc.section.19.p.6"><p>For
 error reporting, we follow the convention of HTTP/1.1 status codes, 
including with each status code a short, English description of the code
 (e.g., 423 (Locked)). While the possibility exists that a poorly 
crafted user agent would display this message to a user, 
internationalized applications will ignore this message, and display an 
appropriate message in the user's language and character set.<a class="self" href="#rfc.section.19.p.6">¶</a></p></div><div id="rfc.section.19.p.7"><p>Since
 interoperation of clients and servers does not require locale 
information, this specification does not specify any mechanism for 
transmission of this information.<a class="self" href="#rfc.section.19.p.7">¶</a></p></div></section><section id="security.considerations"><h2 id="rfc.section.20"><a href="#rfc.section.20">20.</a>&nbsp;<a href="#security.considerations">Security Considerations</a></h2><div id="rfc.section.20.p.1"><p>This section is provided to detail issues concerning security implications of which WebDAV applications need to be aware.<a class="self" href="#rfc.section.20.p.1">¶</a></p></div><div id="rfc.section.20.p.2"><p>All of the security considerations of HTTP/1.1 (discussed in <a href="#RFC2616" id="rfc.xref.RFC2616.45"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>) and XML (discussed in <a href="#RFC3023" id="rfc.xref.RFC3023.3"><cite title="XML Media Types">[RFC3023]</cite></a>)
 also apply to WebDAV. In addition, the security risks inherent in 
remote authoring require stronger authentication technology, introduce 
several new privacy concerns, and may increase the hazards from poor 
server design. These issues are detailed below.<a class="self" href="#rfc.section.20.p.2">¶</a></p></div><section id="n-authentication-of-clients"><h3 id="rfc.section.20.1"><a href="#rfc.section.20.1">20.1</a>&nbsp;<a href="#n-authentication-of-clients">Authentication of Clients</a></h3><div id="rfc.section.20.1.p.1"><p>Due
 to their emphasis on authoring, WebDAV servers need to use 
authentication technology to protect not just access to a network 
resource, but the integrity of the resource as well. Furthermore, the 
introduction of locking functionality requires support for 
authentication.<a class="self" href="#rfc.section.20.1.p.1">¶</a></p></div><div id="rfc.section.20.1.p.2"><p>A
 password sent in the clear over an insecure channel is an inadequate 
means for protecting the accessibility and integrity of a resource as 
the password may be intercepted. Since Basic authentication for HTTP/1.1
 performs essentially clear text transmission of a password, Basic 
authentication <em class="bcp14">MUST NOT</em> be used to authenticate a WebDAV client to a server unless the connection is secure. Furthermore, a WebDAV server <em class="bcp14">MUST NOT</em>
 send a Basic authentication challenge in a WWW-Authenticate header 
unless the connection is secure. An example of a secure connection would
 be a Transport Layer Security (TLS) connection employing a strong 
cipher suite and server authentication.<a class="self" href="#rfc.section.20.1.p.2">¶</a></p></div><div id="rfc.section.20.1.p.3"><p>WebDAV applications <em class="bcp14">MUST</em> support the Digest authentication scheme <a href="#RFC2617" id="rfc.xref.RFC2617.1"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>.
 Since Digest authentication verifies that both parties to a 
communication know a shared secret, a password, without having to send 
that secret in the clear, Digest authentication avoids the security 
problems inherent in Basic authentication while providing a level of 
authentication that is useful in a wide range of scenarios.<a class="self" href="#rfc.section.20.1.p.3">¶</a></p></div></section><section id="n-denial-of-service"><h3 id="rfc.section.20.2"><a href="#rfc.section.20.2">20.2</a>&nbsp;<a href="#n-denial-of-service">Denial of Service</a></h3><div id="rfc.section.20.2.p.1"><p>Denial-of-service
 attacks are of special concern to WebDAV servers. WebDAV plus HTTP 
enables denial-of-service attacks on every part of a system's resources.<a class="self" href="#rfc.section.20.2.p.1">¶</a></p></div><div id="rfc.section.20.2.p.2"><ul><li>The underlying storage can be attacked by PUTting extremely large files.</li><li>Asking for recursive operations on large collections can attack processing time.</li><li>Making multiple pipelined requests on multiple connections can attack network connections.</li></ul></div><div id="rfc.section.20.2.p.3"><p>WebDAV
 servers need to be aware of the possibility of a denial-of-service 
attack at all levels. The proper response to such an attack <em class="bcp14">MAY</em> be to simply drop the connection. Or, if the server is able to make a response, the server <em class="bcp14">MAY</em>
 use a 400-level status request such as 400 (Bad Request) and indicate 
why the request was refused (a 500-level status response would indicate 
that the problem is with the server, whereas unintentional DoS attacks 
are something the client is capable of remedying).<a class="self" href="#rfc.section.20.2.p.3">¶</a></p></div></section><section id="n-security-through-obscurity"><h3 id="rfc.section.20.3"><a href="#rfc.section.20.3">20.3</a>&nbsp;<a href="#n-security-through-obscurity">Security through Obscurity</a></h3><div id="rfc.section.20.3.p.1"><p>WebDAV
 provides, through the PROPFIND method, a mechanism for listing the 
member resources of a collection. This greatly diminishes the 
effectiveness of security or privacy techniques that rely only on the 
difficulty of discovering the names of network resources. Users of 
WebDAV servers are encouraged to use access control techniques to 
prevent unwanted access to resources, rather than depending on the 
relative obscurity of their resource names.<a class="self" href="#rfc.section.20.3.p.1">¶</a></p></div></section><section id="n-privacy-issues-connected-to-locks"><h3 id="rfc.section.20.4"><a href="#rfc.section.20.4">20.4</a>&nbsp;<a href="#n-privacy-issues-connected-to-locks">Privacy Issues Connected to Locks</a></h3><div id="rfc.section.20.4.p.1"><p>When
 submitting a lock request, a user agent may also submit an 'owner' XML 
field giving contact information for the person taking out the lock (for
 those cases where a person, rather than a robot, is taking out the 
lock). This contact information is stored in a DAV:lockdiscovery 
property on the resource, and can be used by other collaborators to 
begin negotiation over access to the resource. However, in many cases, 
this contact information can be very private, and should not be widely 
disseminated. Servers <em class="bcp14">SHOULD</em> limit read access to the DAV:lockdiscovery property as appropriate. Furthermore, user agents <em class="bcp14">SHOULD</em>
 provide control over whether contact information is sent at all, and if
 contact information is sent, control over exactly what information is 
sent.<a class="self" href="#rfc.section.20.4.p.1">¶</a></p></div></section><section id="n-privacy-issues-connected-to-properties"><h3 id="rfc.section.20.5"><a href="#rfc.section.20.5">20.5</a>&nbsp;<a href="#n-privacy-issues-connected-to-properties">Privacy Issues Connected to Properties</a></h3><div id="rfc.section.20.5.p.1"><p>Since
 property values are typically used to hold information such as the 
author of a document, there is the possibility that privacy concerns 
could arise stemming from widespread access to a resource's property 
data. To reduce the risk of inadvertent release of private information 
via properties, servers are encouraged to develop access control 
mechanisms that separate read access to the resource body and read 
access to the resource's properties. This allows a user to control the 
dissemination of their property data without overly restricting access 
to the resource's contents.<a class="self" href="#rfc.section.20.5.p.1">¶</a></p></div></section><section id="n-implications-of-xml-entities"><h3 id="rfc.section.20.6"><a href="#rfc.section.20.6">20.6</a>&nbsp;<a href="#n-implications-of-xml-entities">Implications of XML Entities</a></h3><div id="rfc.section.20.6.p.1"><p>XML supports a facility known as "external entities", defined in <a href="http://www.w3.org/TR/2006/REC-xml-20060816/#sec-external-ent">Section 4.2.2</a> of <a href="#REC-XML" id="rfc.xref.REC-XML.7"><cite title="Extensible Markup Language (XML) 1.0 (Fourth Edition)">[REC-XML]</cite></a>,
 which instructs an XML processor to retrieve and include additional 
XML. An external XML entity can be used to append or modify the document
 type declaration (DTD) associated with an XML document. An external XML
 entity can also be used to include XML within the content of an XML 
document. For non-validating XML, such as the XML used in this 
specification, including an external XML entity is not required by XML. 
However, XML does state that an XML processor may, at its discretion, 
include the external XML entity.<a class="self" href="#rfc.section.20.6.p.1">¶</a></p></div><div id="rfc.section.20.6.p.2"><p>External
 XML entities have no inherent trustworthiness and are subject to all 
the attacks that are endemic to any HTTP GET request. Furthermore, it is
 possible for an external XML entity to modify the DTD, and hence affect
 the final form of an XML document, in the worst case, significantly 
modifying its semantics or exposing the XML processor to the security 
risks discussed in <a href="#RFC3023" id="rfc.xref.RFC3023.4"><cite title="XML Media Types">[RFC3023]</cite></a>.
 Therefore, implementers must be aware that external XML entities should
 be treated as untrustworthy. If a server chooses not to handle external
 XML entities, it <em class="bcp14">SHOULD</em> respond to requests containing external entities with the 'no-external-entities' condition code.<a class="self" href="#rfc.section.20.6.p.2">¶</a></p></div><div id="rfc.section.20.6.p.3"><p>There
 is also the scalability risk that would accompany a widely deployed 
application that made use of external XML entities. In this situation, 
it is possible that there would be significant numbers of requests for 
one external XML entity, potentially overloading any server that fields 
requests for the resource containing the external XML entity.<a class="self" href="#rfc.section.20.6.p.3">¶</a></p></div><div id="rfc.section.20.6.p.4"><p>Furthermore, there's also a risk based on the evaluation of "internal entities" as defined in <a href="http://www.w3.org/TR/2006/REC-xml-20060816/#sec-external-ent">Section 4.2.2</a> of <a href="#REC-XML" id="rfc.xref.REC-XML.8"><cite title="Extensible Markup Language (XML) 1.0 (Fourth Edition)">[REC-XML]</cite></a>.
 A small, carefully crafted request using nested internal entities may 
require enormous amounts of memory and/or processing time to process. 
Server implementers should be aware of this risk and configure their XML
 parsers so that requests like these can be detected and rejected as 
early as possible.<a class="self" href="#rfc.section.20.6.p.4">¶</a></p></div></section><section id="risks.connected.with.lock.tokens"><h3 id="rfc.section.20.7"><a href="#rfc.section.20.7">20.7</a>&nbsp;<a href="#risks.connected.with.lock.tokens">Risks Connected with Lock Tokens</a></h3><div id="rfc.section.20.7.p.1"><p>This specification encourages the use of "A Universally Unique Identifier (UUID) URN Namespace" (<a href="#RFC4122" id="rfc.xref.RFC4122.2"><cite title="A Universally Unique IDentifier (UUID) URN Namespace">[RFC4122]</cite></a>) for lock tokens (<a href="#lock-tokens" title="Lock Tokens">Section&nbsp;6.5</a>), in order to guarantee their uniqueness across space and time. Version 1 UUIDs (defined in <a href="https://tools.ietf.org/html/rfc4122#section-4" id="rfc.xref.RFC4122.3">Section 4</a>) <em class="bcp14">MAY</em>
 contain a "node" field that "consists of an IEEE 802 MAC address, 
usually the host address. For systems with multiple IEEE addresses, any 
available one can be used". Since a WebDAV server will issue many locks 
over its lifetime, the implication is that it may also be publicly 
exposing its IEEE 802 address.<a class="self" href="#rfc.section.20.7.p.1">¶</a></p></div><div id="rfc.section.20.7.p.2" class="avoidbreakafter"><p>There are several risks associated with exposure of IEEE 802 addresses. Using the IEEE 802 address:<a class="self" href="#rfc.section.20.7.p.2">¶</a></p></div><div id="rfc.section.20.7.p.3"><ul><li>It is possible to track the movement of hardware from subnet to subnet.</li><li>It may be possible to identify the manufacturer of the hardware running a WebDAV server.</li><li>It may be possible to determine the number of each type of computer running WebDAV.</li></ul></div><div id="rfc.section.20.7.p.4"><p>This risk only applies to host-address-based UUID versions. <a href="https://tools.ietf.org/html/rfc4122#section-4">Section 4</a> of <a href="#RFC4122" id="rfc.xref.RFC4122.4"><cite title="A Universally Unique IDentifier (UUID) URN Namespace">[RFC4122]</cite></a>
 describes several other mechanisms for generating UUIDs that do not 
involve the host address and therefore do not suffer from this risk.<a class="self" href="#rfc.section.20.7.p.4">¶</a></p></div></section><section id="n-hosting-malicious-content"><h3 id="rfc.section.20.8"><a href="#rfc.section.20.8">20.8</a>&nbsp;<a href="#n-hosting-malicious-content">Hosting Malicious Content</a></h3><div id="rfc.section.20.8.p.1"><p>HTTP
 has the ability to host programs that are executed on client machines. 
These programs can take many forms including Web scripts, executables, 
plug-in modules, and macros in documents. WebDAV does not change any of 
the security concerns around these programs, yet often WebDAV is used in
 contexts where a wide range of users can publish documents on a server.
 The server might not have a close trust relationship with the author 
that is publishing the document. Servers that allow clients to publish 
arbitrary content can usefully implement precautions to check that 
content published to the server is not harmful to other clients. Servers
 could do this by techniques such as restricting the types of content 
that is allowed to be published and running virus and malware detection 
software on published content. Servers can also mitigate the risk by 
having appropriate access restriction and authentication of users that 
are allowed to publish content to the server.<a class="self" href="#rfc.section.20.8.p.1">¶</a></p></div></section></section><section id="n-iana-considerations"><h2 id="rfc.section.21"><a href="#rfc.section.21">21.</a>&nbsp;<a href="#n-iana-considerations">IANA Considerations</a></h2><section id="n-new-uri-schemes"><h3 id="rfc.section.21.1"><a href="#rfc.section.21.1">21.1</a>&nbsp;<a href="#n-new-uri-schemes">New URI Schemes</a></h3><div id="rfc.section.21.1.p.1"><p>This specification defines two URI schemes: <a class="self" href="#rfc.section.21.1.p.1">¶</a></p><ol><li>the "opaquelocktoken" scheme defined in <a href="#opaquelocktoken.lock.token.uri.scheme" title="The 'opaquelocktoken' Scheme and URIs">Appendix&nbsp;C</a>, and</li><li><span id="rfc.iref.d.9"></span> <span id="rfc.iref.u.5"></span> the "DAV" URI scheme, which historically was used in <a href="#RFC2518" id="rfc.xref.RFC2518.7"><cite title="HTTP Extensions for Distributed Authoring -- WEBDAV">[RFC2518]</cite></a>
 to disambiguate WebDAV property and XML element names and which 
continues to be used for that purpose in this specification and others 
extending WebDAV. Creation of identifiers in the "DAV:" namespace is 
controlled by the IETF.</li></ol></div><div id="rfc.section.21.1.p.2"><p>Note
 that defining new URI schemes for XML namespaces is now discouraged. 
"DAV:" was defined before standard best practices emerged.<a class="self" href="#rfc.section.21.1.p.2">¶</a></p></div></section><section id="n-xml-namespaces"><h3 id="rfc.section.21.2"><a href="#rfc.section.21.2">21.2</a>&nbsp;<a href="#n-xml-namespaces">XML Namespaces</a></h3><div id="rfc.section.21.2.p.1"><p>XML
 namespaces disambiguate WebDAV property names and XML elements. Any 
WebDAV user or application can define a new namespace in order to create
 custom properties or extend WebDAV XML syntax. IANA does not need to 
manage such namespaces, property names, or element names.<a class="self" href="#rfc.section.21.2.p.1">¶</a></p></div></section><section id="n-message-header-fields"><h3 id="rfc.section.21.3"><a href="#rfc.section.21.3">21.3</a>&nbsp;<a href="#n-message-header-fields">Message Header Fields</a></h3><div id="rfc.section.21.3.p.1"><p>The message header fields below should be added to the permanent registry (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>).<a class="self" href="#rfc.section.21.3.p.1">¶</a></p></div><section id="n-dav"><h4 id="rfc.section.21.3.1"><a href="#rfc.section.21.3.1">21.3.1</a>&nbsp;<a href="#n-dav">DAV</a></h4><div id="rfc.section.21.3.1.p.1"><p>Header field name: DAV<a class="self" href="#rfc.section.21.3.1.p.1">¶</a></p></div><div id="rfc.section.21.3.1.p.2"><p>Applicable protocol: http<a class="self" href="#rfc.section.21.3.1.p.2">¶</a></p></div><div id="rfc.section.21.3.1.p.3"><p>Status: standard<a class="self" href="#rfc.section.21.3.1.p.3">¶</a></p></div><div id="rfc.section.21.3.1.p.4"><p>Author/Change controller: IETF<a class="self" href="#rfc.section.21.3.1.p.4">¶</a></p></div><div id="rfc.section.21.3.1.p.5"><p>Specification document: this specification (<a href="#HEADER_DAV" title="DAV Header">Section&nbsp;10.1</a>)<a class="self" href="#rfc.section.21.3.1.p.5">¶</a></p></div></section><section id="n-depth"><h4 id="rfc.section.21.3.2"><a href="#rfc.section.21.3.2">21.3.2</a>&nbsp;<a href="#n-depth">Depth</a></h4><div id="rfc.section.21.3.2.p.1"><p>Header field name: Depth<a class="self" href="#rfc.section.21.3.2.p.1">¶</a></p></div><div id="rfc.section.21.3.2.p.2"><p>Applicable protocol: http<a class="self" href="#rfc.section.21.3.2.p.2">¶</a></p></div><div id="rfc.section.21.3.2.p.3"><p>Status: standard<a class="self" href="#rfc.section.21.3.2.p.3">¶</a></p></div><div id="rfc.section.21.3.2.p.4"><p>Author/Change controller: IETF<a class="self" href="#rfc.section.21.3.2.p.4">¶</a></p></div><div id="rfc.section.21.3.2.p.5"><p>Specification document: this specification (<a href="#HEADER_Depth" title="Depth Header">Section&nbsp;10.2</a>)<a class="self" href="#rfc.section.21.3.2.p.5">¶</a></p></div></section><section id="n-destination"><h4 id="rfc.section.21.3.3"><a href="#rfc.section.21.3.3">21.3.3</a>&nbsp;<a href="#n-destination">Destination</a></h4><div id="rfc.section.21.3.3.p.1"><p>Header field name: Destination<a class="self" href="#rfc.section.21.3.3.p.1">¶</a></p></div><div id="rfc.section.21.3.3.p.2"><p>Applicable protocol: http<a class="self" href="#rfc.section.21.3.3.p.2">¶</a></p></div><div id="rfc.section.21.3.3.p.3"><p>Status: standard<a class="self" href="#rfc.section.21.3.3.p.3">¶</a></p></div><div id="rfc.section.21.3.3.p.4"><p>Author/Change controller: IETF<a class="self" href="#rfc.section.21.3.3.p.4">¶</a></p></div><div id="rfc.section.21.3.3.p.5"><p>Specification document: this specification (<a href="#HEADER_Destination" title="Destination Header">Section&nbsp;10.3</a>)<a class="self" href="#rfc.section.21.3.3.p.5">¶</a></p></div></section><section id="n-if"><h4 id="rfc.section.21.3.4"><a href="#rfc.section.21.3.4">21.3.4</a>&nbsp;<a href="#n-if">If</a></h4><div id="rfc.section.21.3.4.p.1"><p>Header field name: If<a class="self" href="#rfc.section.21.3.4.p.1">¶</a></p></div><div id="rfc.section.21.3.4.p.2"><p>Applicable protocol: http<a class="self" href="#rfc.section.21.3.4.p.2">¶</a></p></div><div id="rfc.section.21.3.4.p.3"><p>Status: standard<a class="self" href="#rfc.section.21.3.4.p.3">¶</a></p></div><div id="rfc.section.21.3.4.p.4"><p>Author/Change controller: IETF<a class="self" href="#rfc.section.21.3.4.p.4">¶</a></p></div><div id="rfc.section.21.3.4.p.5"><p>Specification document: this specification (<a href="#HEADER_If" title="If Header">Section&nbsp;10.4</a>)<a class="self" href="#rfc.section.21.3.4.p.5">¶</a></p></div></section><section id="n-lock-token"><h4 id="rfc.section.21.3.5"><a href="#rfc.section.21.3.5">21.3.5</a>&nbsp;<a href="#n-lock-token">Lock-Token</a></h4><div id="rfc.section.21.3.5.p.1"><p>Header field name: Lock-Token<a class="self" href="#rfc.section.21.3.5.p.1">¶</a></p></div><div id="rfc.section.21.3.5.p.2"><p>Applicable protocol: http<a class="self" href="#rfc.section.21.3.5.p.2">¶</a></p></div><div id="rfc.section.21.3.5.p.3"><p>Status: standard<a class="self" href="#rfc.section.21.3.5.p.3">¶</a></p></div><div id="rfc.section.21.3.5.p.4"><p>Author/Change controller: IETF<a class="self" href="#rfc.section.21.3.5.p.4">¶</a></p></div><div id="rfc.section.21.3.5.p.5"><p>Specification document: this specification (<a href="#HEADER_Lock-Token" title="Lock-Token Header">Section&nbsp;10.5</a>)<a class="self" href="#rfc.section.21.3.5.p.5">¶</a></p></div></section><section id="n-overwrite"><h4 id="rfc.section.21.3.6"><a href="#rfc.section.21.3.6">21.3.6</a>&nbsp;<a href="#n-overwrite">Overwrite</a></h4><div id="rfc.section.21.3.6.p.1"><p>Header field name: Overwrite<a class="self" href="#rfc.section.21.3.6.p.1">¶</a></p></div><div id="rfc.section.21.3.6.p.2"><p>Applicable protocol: http<a class="self" href="#rfc.section.21.3.6.p.2">¶</a></p></div><div id="rfc.section.21.3.6.p.3"><p>Status: standard<a class="self" href="#rfc.section.21.3.6.p.3">¶</a></p></div><div id="rfc.section.21.3.6.p.4"><p>Author/Change controller: IETF<a class="self" href="#rfc.section.21.3.6.p.4">¶</a></p></div><div id="rfc.section.21.3.6.p.5"><p>Specification document: this specification (<a href="#HEADER_Overwrite" title="Overwrite Header">Section&nbsp;10.6</a>)<a class="self" href="#rfc.section.21.3.6.p.5">¶</a></p></div></section><section id="n-timeout"><h4 id="rfc.section.21.3.7"><a href="#rfc.section.21.3.7">21.3.7</a>&nbsp;<a href="#n-timeout">Timeout</a></h4><div id="rfc.section.21.3.7.p.1"><p>Header field name: Timeout<a class="self" href="#rfc.section.21.3.7.p.1">¶</a></p></div><div id="rfc.section.21.3.7.p.2"><p>Applicable protocol: http<a class="self" href="#rfc.section.21.3.7.p.2">¶</a></p></div><div id="rfc.section.21.3.7.p.3"><p>Status: standard<a class="self" href="#rfc.section.21.3.7.p.3">¶</a></p></div><div id="rfc.section.21.3.7.p.4"><p>Author/Change controller: IETF<a class="self" href="#rfc.section.21.3.7.p.4">¶</a></p></div><div id="rfc.section.21.3.7.p.5"><p>Specification document: this specification (<a href="#HEADER_Timeout" title="Timeout Request Header">Section&nbsp;10.7</a>)<a class="self" href="#rfc.section.21.3.7.p.5">¶</a></p></div></section></section><section id="n-http-status-codes"><h3 id="rfc.section.21.4"><a href="#rfc.section.21.4">21.4</a>&nbsp;<a href="#n-http-status-codes">HTTP Status Codes</a></h3><div id="rfc.section.21.4.p.1"><p>This specification defines the HTTP status codes <a class="self" href="#rfc.section.21.4.p.1">¶</a></p><ul><li>207 Multi-Status (<a href="#STATUS_207" title="207 Multi-Status">Section&nbsp;11.1</a>)</li><li>422 Unprocessable Entity (<a href="#STATUS_422" title="422 Unprocessable Entity">Section&nbsp;11.2</a>),</li><li>423 Locked (<a href="#STATUS_423" title="423 Locked">Section&nbsp;11.3</a>),</li><li>424 Failed Dependency (<a href="#STATUS_424" title="424 Failed Dependency">Section&nbsp;11.4</a>) and</li><li>507 Insufficient Storage (<a href="#STATUS_507" title="507 Insufficient Storage">Section&nbsp;11.5</a>),</li></ul><p> to be updated in the registry at &lt;<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>&gt;.</p></div><div id="STATUS_102"><div id="rfc.section.21.4.p.2"><p><span id="rfc.iref.1.1"></span> <span id="rfc.iref.s.2"></span>
 Note: the HTTP status code 102 (Processing) has been removed in this 
specification; its IANA registration should continue to reference <cite title="HTTP Extensions for Distributed Authoring -- WEBDAV" id="rfc.xref.RFC2518.8">RFC 2518</cite>.<a class="self" href="#rfc.section.21.4.p.2">¶</a></p></div></div></section></section><section id="n-acknowledgements"><h2 id="rfc.section.22"><a href="#rfc.section.22">22.</a>&nbsp;<a href="#n-acknowledgements">Acknowledgements</a></h2><div id="rfc.section.22.p.1"><p>A
 specification such as this thrives on piercing critical review and 
withers from apathetic neglect. The authors gratefully acknowledge the 
contributions of the following people, whose insights were so valuable 
at every stage of our work.<a class="self" href="#rfc.section.22.p.1">¶</a></p></div><div id="rfc.section.22.p.2"><p><b>Contributors to RFC 2518</b> <a class="self" href="#rfc.section.22.p.2">¶</a></p></div><div id="rfc.section.22.p.3"><p>Terry
 Allen, Harald Alvestrand, Jim Amsden, Becky Anderson, Alan Babich, 
Sanford Barr, Dylan Barrell, Bernard Chester, Tim Berners-Lee, Dan 
Connolly, Jim Cunningham, Ron Daniel, Jr., Jim Davis, Keith Dawson, Mark
 Day, Brian Deen, Martin Duerst, David Durand, Lee Farrell, Chuck Fay, 
Wesley Felter, Roy Fielding, Mark Fisher, Alan Freier, George 
Florentine, Jim Gettys, Phill Hallam-Baker, Dennis Hamilton, Steve 
Henning, Mead Himelstein, Alex Hopmann, Andre van der Hoek, Ben Laurie, 
Paul Leach, Ora Lassila, Karen MacArthur, Steven Martin, Larry Masinter,
 Michael Mealling, Keith Moore, Thomas Narten, Henrik Nielsen, Kenji 
Ota, Bob Parker, Glenn Peterson, Jon Radoff, Saveen Reddy, Henry 
Sanders, Christopher Seiwald, Judith Slein, Mike Spreitzer, Einar 
Stefferud, Greg Stein, Ralph Swick, Kenji Takahashi, Richard N. Taylor, 
Robert Thau, John Turner, Sankar Virdhagriswaran, Fabio Vitali, Gregory 
Woodhouse, and Lauren Wood.<a class="self" href="#rfc.section.22.p.3">¶</a></p></div><div id="rfc.section.22.p.4"><p>Two
 from this list deserve special mention. The contributions by Larry 
Masinter have been invaluable; he both helped the formation of the 
working group and patiently coached the authors along the way. In so 
many ways he has set high standards that we have toiled to meet. The 
contributions of Judith Slein were also invaluable; by clarifying the 
requirements and in patiently reviewing version after version, she both 
improved this specification and expanded our minds on document 
management.<a class="self" href="#rfc.section.22.p.4">¶</a></p></div><div id="rfc.section.22.p.5"><p>We would also like to thank John Turner for developing the XML DTD.<a class="self" href="#rfc.section.22.p.5">¶</a></p></div><div id="rfc.section.22.p.6"><p>The
 authors of RFC 2518 were Yaron Goland, Jim Whitehead, A. Faizi, Steve 
Carter, and D. Jensen. Although their names had to be removed due to 
IETF author count restrictions, they can take credit for the majority of
 the design of WebDAV.<a class="self" href="#rfc.section.22.p.6">¶</a></p></div><div id="rfc.section.22.p.7"><p><b>Additional Acknowledgements for This Specification</b> <a class="self" href="#rfc.section.22.p.7">¶</a></p></div><div id="rfc.section.22.p.8"><p>Significant
 contributors of text for this specification are listed as contributors 
in the section below. We must also gratefully acknowledge Geoff Clemm, 
Joel Soderberg, and Dan Brotsky for hashing out specific text on the 
list or in meetings. Joe Hildebrand and Cullen Jennings helped close 
many issues. Barry Lind described an additional security consideration 
and Cullen Jennings provided text for that consideration. Jason Crawford
 tracked issue status for this document for a period of years, followed 
by Elias Sinderson.<a class="self" href="#rfc.section.22.p.8">¶</a></p></div></section><section id="n-contributors-to-this-specification"><h2 id="rfc.section.23"><a href="#rfc.section.23">23.</a>&nbsp;<a href="#n-contributors-to-this-specification">Contributors to This Specification</a></h2><div id="rfc.figure.u.107"><pre class="inline">  Julian Reschke
  &lt;green/&gt;bytes GmbH
  Hafenweg 16, 48155 Muenster, Germany
  EMail: julian.reschke@greenbytes.de
</pre></div><div id="rfc.figure.u.108"><pre class="inline">  Elias Sinderson
  University of California, Santa Cruz
  1156 High Street, Santa Cruz, CA 95064  
  EMail: elias@cse.ucsc.edu
</pre></div><div id="rfc.figure.u.109"><pre class="inline">  Jim Whitehead
  University of California, Santa Cruz
  1156 High Street, Santa Cruz, CA 95064  
  EMail: ejw@soe.ucsc.edu
</pre></div></section><section id="n-authors-of-rfc-2518"><h2 id="rfc.section.24"><a href="#rfc.section.24">24.</a>&nbsp;<a href="#n-authors-of-rfc-2518">Authors of RFC 2518</a></h2><div id="rfc.figure.u.110"><pre class="inline">  Y. Y. Goland 
  Microsoft Corporation 
  One Microsoft Way 
  Redmond, WA 98052-6399 
  EMail: yarong@microsoft.com
</pre></div><div id="rfc.figure.u.111"><pre class="inline">  E. J. Whitehead, Jr. 
  Dept. Of Information and Computer Science 
  University of California, Irvine
  Irvine, CA 92697-3425
  EMail: ejw@ics.uci.edu
</pre></div><div id="rfc.figure.u.112"><pre class="inline">  A. Faizi
  Netscape 
  685 East Middlefield Road 
  Mountain View, CA 94043
  EMail: asad@netscape.com 
</pre></div><div id="rfc.figure.u.113"><pre class="inline">  S. R. Carter
  Novell
  1555 N. Technology Way 
  M/S ORM F111
  Orem, UT 84097-2399
  EMail: srcarter@novell.com
</pre></div><div id="rfc.figure.u.114"><pre class="inline">  D. Jensen 
  Novell 
  1555 N. Technology Way 
  M/S ORM F111 
  Orem, UT 84097-2399 
  EMail: dcjensen@novell.com
</pre></div></section><section id="rfc.references"><h2 id="rfc.section.25"><a href="#rfc.section.25">25.</a> References</h2><section id="rfc.references.1"><h3 id="rfc.section.25.1"><a href="#rfc.section.25.1">25.1</a> Normative References</h3><dl class="reference"><dt id="REC-XML">[REC-XML]</dt><dd><a href="mailto:tbray@textuality.com">Bray, T.</a>, <a href="mailto:jeanpa@microsoft.com">Paoli, J.</a>, <a href="mailto:cmsmcq@w3.org">Sperberg-McQueen, C.</a>, <a href="mailto:eve.maler@east.sun.com">Maler, E.</a>, and <a href="mailto:francois@yergeau.com">F. Yergeau</a>, “<a href="http://www.w3.org/TR/2006/REC-xml-20060816/">Extensible Markup Language (XML) 1.0 (Fourth Edition)</a>”, W3C&nbsp;REC-xml-20060816, August&nbsp;2006, &lt;<a href="http://www.w3.org/TR/2006/REC-xml-20060816/">http://www.w3.org/TR/2006/REC-xml-20060816/</a>&gt;.</dd><dt id="REC-XML-INFOSET">[REC-XML-INFOSET]</dt><dd><a href="mailto:jcowan@reutershealth.com">Cowan, J.</a> and <a href="mailto:richard@cogsci.ed.ac.uk">R. Tobin</a>, “<a href="http://www.w3.org/TR/2004/REC-xml-infoset-20040204/">XML Information Set (Second Edition)</a>”, W3C&nbsp;REC-xml-infoset-20040204, February&nbsp;2004, &lt;<a href="http://www.w3.org/TR/2004/REC-xml-infoset-20040204/">http://www.w3.org/TR/2004/REC-xml-infoset-20040204/</a>&gt;.</dd><dt id="REC-XML-NAMES">[REC-XML-NAMES]</dt><dd><a href="mailto:tbray@textuality.com">Bray, T.</a>, <a href="mailto:dmh@contivo.com">Hollander, D.</a>, <a href="mailto:andrewl@microsoft.com">Layman, A.</a>, and <a href="mailto:richard@cogsci.ed.ac.uk">R. Tobin</a>, “<a href="http://www.w3.org/TR/2006/REC-xml-names-20060816/">Namespaces in XML 1.0 (Second Edition)</a>”, W3C&nbsp;REC-xml-names-20060816, August&nbsp;2006, &lt;<a href="http://www.w3.org/TR/2006/REC-xml-names-20060816/">http://www.w3.org/TR/2006/REC-xml-names-20060816/</a>&gt;.</dd><dt id="RFC2119">[RFC2119]</dt><dd><a href="mailto:sob@harvard.edu">Bradner, S.</a>, “<a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>”, BCP&nbsp;14, RFC&nbsp;2119, March&nbsp;1997.</dd><dt id="RFC2277">[RFC2277]</dt><dd><a href="mailto:Harald.T.Alvestrand@uninett.no">Alvestrand, H.</a>, “<a href="https://tools.ietf.org/html/rfc2277">IETF Policy on Character Sets and Languages</a>”, BCP&nbsp;18, RFC&nbsp;2277, January&nbsp;1998.</dd><dt id="RFC2616">[RFC2616]</dt><dd><a href="mailto:fielding@ics.uci.edu">Fielding, R.</a>, <a href="mailto:jg@w3.org">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com">Mogul, J.</a>, <a href="mailto:frystyk@w3.org">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com">Leach, P.</a>, and <a href="mailto:timbl@w3.org">T. Berners-Lee</a>, “<a href="https://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC&nbsp;2616, June&nbsp;1999.</dd><dt id="RFC2617">[RFC2617]</dt><dd><a href="mailto:john@math.nwu.edu">Franks, J.</a>, <a href="mailto:pbaker@verisign.com">Hallam-Baker, P.</a>, <a href="mailto:jeff@AbiSource.com">Hostetler, J.</a>, <a href="mailto:lawrence@agranat.com">Lawrence, S.</a>, <a href="mailto:paulle@microsoft.com">Leach, P.</a>, Luotonen, A., and <a href="mailto:stewart@OpenMarket.com">L. Stewart</a>, “<a href="https://tools.ietf.org/html/rfc2617">HTTP Authentication: Basic and Digest Access Authentication</a>”, RFC&nbsp;2617, June&nbsp;1999.</dd><dt id="RFC3339">[RFC3339]</dt><dd><a href="mailto:GK@ACM.ORG">Klyne, G., Ed.</a> and <a href="mailto:chris.newman@sun.com">C. Newman</a>, “<a href="https://tools.ietf.org/html/rfc3339">Date and Time on the Internet: Timestamps</a>”, RFC&nbsp;3339, July&nbsp;2002.</dd><dt id="RFC3629">[RFC3629]</dt><dd>Yergeau, F., “<a href="https://tools.ietf.org/html/rfc3629">UTF-8, a transformation format of ISO 10646</a>”, STD&nbsp;63, RFC&nbsp;3629, November&nbsp;2003.</dd><dt id="RFC3986">[RFC3986]</dt><dd><a href="mailto:timbl@w3.org">Berners-Lee, T.</a>, <a href="mailto:fielding@gbiv.com">Fielding, R.</a>, and <a href="mailto:LMM@acm.org">L. Masinter</a>, “<a href="https://tools.ietf.org/html/rfc3986">Uniform Resource Identifier (URI): Generic Syntax</a>”, STD&nbsp;66, RFC&nbsp;3986, January&nbsp;2005.</dd><dt id="RFC4122">[RFC4122]</dt><dd><a href="mailto:paulle@microsoft.com">Leach, P.</a>, <a href="mailto:michael@refactored-networks.com">Mealling, M.</a>, and <a href="mailto:rsalz@datapower.com">R. Salz</a>, “<a href="https://tools.ietf.org/html/rfc4122">A Universally Unique IDentifier (UUID) URN Namespace</a>”, RFC&nbsp;4122, July&nbsp;2005.</dd></dl></section><section id="rfc.references.2"><h3 id="rfc.section.25.2"><a href="#rfc.section.25.2">25.2</a> Informative References</h3><dl class="reference"><dt id="RFC2291">[RFC2291]</dt><dd><a href="mailto:slein@wrc.xerox.com">Slein, J.</a>, <a href="mailto:fabio@cs.unibo.it">Vitali, F.</a>, <a href="mailto:ejw@ics.uci.edu">Whitehead, E.</a>, and <a href="mailto:dgd@cs.bu.edu">D. Durand</a>, “<a href="https://tools.ietf.org/html/rfc2291">Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web</a>”, RFC&nbsp;2291, February&nbsp;1998.</dd><dt id="RFC2518">[RFC2518]</dt><dd><a href="mailto:yarong@microsoft.com">Goland, Y.</a>, <a href="mailto:ejw@ics.uci.edu">Whitehead, E.</a>, <a href="mailto:asad@netscape.com">Faizi, A.</a>, <a href="mailto:srcarter@novell.com">Carter, S.</a>, and <a href="mailto:dcjensen@novell.com">D. Jensen</a>, “<a href="https://tools.ietf.org/html/rfc2518">HTTP Extensions for Distributed Authoring -- WEBDAV</a>”, RFC&nbsp;2518, February&nbsp;1999.</dd><dt id="RFC2781">[RFC2781]</dt><dd><a href="mailto:phoffman@imc.org">Hoffman, P.</a> and <a href="mailto:fyergeau@alis.com">F. Yergeau</a>, “<a href="https://tools.ietf.org/html/rfc2781">UTF-16, an encoding of ISO 10646</a>”, RFC&nbsp;2781, February&nbsp;2000.</dd><dt id="RFC3023">[RFC3023]</dt><dd>Murata, M., St. Laurent, S., and D. Kohn, “<a href="https://tools.ietf.org/html/rfc3023">XML Media Types</a>”, RFC&nbsp;3023, January&nbsp;2001.</dd><dt id="RFC3253">[RFC3253]</dt><dd><a href="mailto:geoffrey.clemm@rational.com">Clemm, G.</a>, <a href="mailto:jamsden@us.ibm.com">Amsden, J.</a>, <a href="mailto:tim_ellison@uk.ibm.com">Ellison, T.</a>, <a href="mailto:ckaler@microsoft.com">Kaler, C.</a>, and <a href="mailto:ejw@cse.ucsc.edu">J. Whitehead</a>, “<a href="https://tools.ietf.org/html/rfc3253">Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)</a>”, RFC&nbsp;3253, March&nbsp;2002.</dd><dt id="RFC3648">[RFC3648]</dt><dd><a href="mailto:ejw@cse.ucsc.edu">Whitehead, J.</a> and <a href="mailto:julian.reschke@greenbytes.de">J. Reschke, Ed.</a>, “<a href="https://tools.ietf.org/html/rfc3648">Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol</a>”, RFC&nbsp;3648, December&nbsp;2003.</dd><dt id="RFC3744">[RFC3744]</dt><dd><a href="mailto:geoffrey.clemm@us.ibm.com">Clemm, G.</a>, <a href="mailto:julian.reschke@greenbytes.de">Reschke, J.</a>, <a href="mailto:eric.sedlar@oracle.com">Sedlar, E.</a>, and <a href="mailto:ejw@cse.ucsc.edu">J. Whitehead</a>, “<a href="https://tools.ietf.org/html/rfc3744">Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol</a>”, RFC&nbsp;3744, May&nbsp;2004.</dd><dt id="RFC3864">[RFC3864]</dt><dd>Klyne, G., Nottingham, M., and J. Mogul, “<a href="https://tools.ietf.org/html/rfc3864">Registration Procedures for Message Header Fields</a>”, BCP&nbsp;90, RFC&nbsp;3864, September&nbsp;2004.</dd></dl></section></section><section id="xml-appendix"><h2 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;<a href="#xml-appendix">Notes on Processing XML Elements</a></h2><section id="n-notes-on-empty-xml-elements"><h3 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a>&nbsp;<a href="#n-notes-on-empty-xml-elements">Notes on Empty XML Elements</a></h3><div id="rfc.section.A.1.p.1"><p>XML
 supports two mechanisms for indicating that an XML element does not 
have any content. The first is to declare an XML element of the form 
&lt;A&gt;&lt;/A&gt;. The second is to declare an XML element of the form
 &lt;A/&gt;. The two XML elements are semantically identical.<a class="self" href="#rfc.section.A.1.p.1">¶</a></p></div></section><section id="n-notes-on-illegal-xml-processing"><h3 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a>&nbsp;<a href="#n-notes-on-illegal-xml-processing">Notes on Illegal XML Processing</a></h3><div id="rfc.section.A.2.p.1"><p>XML
 is a flexible data format that makes it easy to submit data that 
appears legal but in fact is not. The philosophy of "Be flexible in what
 you accept and strict in what you send" still applies, but it must not 
be applied inappropriately. XML is extremely flexible in dealing with 
issues of whitespace, element ordering, inserting new elements, etc. 
This flexibility does not require extension, especially not in the area 
of the meaning of elements.<a class="self" href="#rfc.section.A.2.p.1">¶</a></p></div><div id="rfc.section.A.2.p.2"><p>There
 is no kindness in accepting illegal combinations of XML elements. At 
best, it will cause an unwanted result and at worst it can cause real 
damage.<a class="self" href="#rfc.section.A.2.p.2">¶</a></p></div></section><section id="n-example---xml-syntax-error"><h3 id="rfc.section.A.3"><a href="#rfc.section.A.3">A.3</a>&nbsp;<a href="#n-example---xml-syntax-error">Example - XML Syntax Error</a></h3><div id="rfc.section.A.3.p.1"><p>The following request body for a PROPFIND method is illegal.<a class="self" href="#rfc.section.A.3.p.1">¶</a></p></div><div id="rfc.figure.u.115"><pre class="text">   &lt;?xml version="1.0" encoding="utf-8" ?&gt; 
   &lt;D:propfind xmlns:D="DAV:"&gt; 
    &lt;D:allprop/&gt; 
    &lt;D:propname/&gt; 
   &lt;/D:propfind&gt; 
</pre></div><div id="rfc.section.A.3.p.2"><p>The definition of the 
propfind element only allows for the allprop or the propname element, 
not both. Thus, the above is an error and must be responded to with a 
400 (Bad Request).<a class="self" href="#rfc.section.A.3.p.2">¶</a></p></div><div id="rfc.section.A.3.p.3"><p>Imagine,
 however, that a server wanted to be "kind" and decided to pick the 
allprop element as the true element and respond to it. A client running 
over a bandwidth limited line who intended to execute a propname would 
be in for a big surprise if the server treated the command as an 
allprop.<a class="self" href="#rfc.section.A.3.p.3">¶</a></p></div><div id="rfc.section.A.3.p.4"><p>Additionally,
 if a server were lenient and decided to reply to this request, the 
results would vary randomly from server to server, with some servers 
executing the allprop directive, and others executing the propname 
directive. This reduces interoperability rather than increasing it.<a class="self" href="#rfc.section.A.3.p.4">¶</a></p></div></section><section id="n-example---unexpected-xml-element"><h3 id="rfc.section.A.4"><a href="#rfc.section.A.4">A.4</a>&nbsp;<a href="#n-example---unexpected-xml-element">Example - Unexpected XML Element</a></h3><div id="rfc.section.A.4.p.1"><p>The
 previous example was illegal because it contained two elements that 
were explicitly banned from appearing together in the propfind element. 
However, XML is an extensible language, so one can imagine new elements 
being defined for use with propfind. Below is the request body of a 
PROPFIND and, like the previous example, must be rejected with a 400 
(Bad Request) by a server that does not understand the expired-props 
element.<a class="self" href="#rfc.section.A.4.p.1">¶</a></p></div><div id="rfc.figure.u.116"><pre class="text">   &lt;?xml version="1.0" encoding="utf-8" ?&gt; 
   &lt;D:propfind xmlns:D="DAV:" 
   xmlns:E="http://www.example.com/standards/props/"&gt; 
    &lt;E:expired-props/&gt; 
   &lt;/D:propfind&gt; 
</pre></div><div id="rfc.section.A.4.p.2"><p>To understand why a 400 
(Bad Request) is returned, let us look at the request body as the server
 unfamiliar with expired-props sees it.<a class="self" href="#rfc.section.A.4.p.2">¶</a></p></div><div id="rfc.figure.u.117"><pre class="text">   &lt;?xml version="1.0" encoding="utf-8" ?&gt; 
   &lt;D:propfind xmlns:D="DAV:"   
               xmlns:E="http://www.example.com/standards/props/"&gt; 
   &lt;/D:propfind&gt; 
</pre></div><div id="rfc.section.A.4.p.3"><p>As the server does not 
understand the 'expired-props' element, according to the WebDAV-specific
 XML processing rules specified in <a href="#xml-extensibility" title="XML Extensibility in DAV">Section&nbsp;17</a>,
 it must process the request as if the element were not there. Thus, the
 server sees an empty propfind, which by the definition of the propfind 
element is illegal.<a class="self" href="#rfc.section.A.4.p.3">¶</a></p></div><div id="rfc.section.A.4.p.4" class="avoidbreakafter"><p>Please
 note that had the extension been additive, it would not necessarily 
have resulted in a 400 (Bad Request). For example, imagine the following
 request body for a PROPFIND:<a class="self" href="#rfc.section.A.4.p.4">¶</a></p></div><div id="rfc.figure.u.118"><pre class="text">   &lt;?xml version="1.0" encoding="utf-8" ?&gt; 
   &lt;D:propfind xmlns:D="DAV:"  
               xmlns:E="http://www.example.com/standards/props/"&gt; 
    &lt;D:propname/&gt; 
    &lt;E:leave-out&gt;*boss*&lt;/E:leave-out&gt; 
   &lt;/D:propfind&gt; 
</pre></div><div id="rfc.section.A.4.p.5"><p>The previous example 
contains the fictitious element leave-out. Its purpose is to prevent the
 return of any property whose name matches the submitted pattern. If the
 previous example were submitted to a server unfamiliar with 
'leave-out', the only result would be that the 'leave-out' element would
 be ignored and a propname would be executed.<a class="self" href="#rfc.section.A.4.p.5">¶</a></p></div></section></section><section id="n-notes-on-http-client-compatibility"><h2 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a href="#n-notes-on-http-client-compatibility">Notes on HTTP Client Compatibility</a></h2><div id="rfc.section.B.p.1"><p>WebDAV
 was designed to be, and has been found to be, backward-compatible with 
HTTP 1.1. The PUT and DELETE methods are defined in HTTP and thus may be
 used by HTTP clients as well as WebDAV-aware clients, but the responses
 to PUT and DELETE have been extended in this specification in ways that
 only a WebDAV client would be entirely prepared for. Some theoretical 
concerns were raised about whether those responses would cause 
interoperability problems with HTTP-only clients, and this section 
addresses those concerns.<a class="self" href="#rfc.section.B.p.1">¶</a></p></div><div id="rfc.section.B.p.2"><p>Since
 any HTTP client ought to handle unrecognized 400-level and 500-level 
status codes as errors, the following new status codes should not 
present any issues: 422, 423, and 507 (424 is also a new status code but
 it appears only in the body of a Multistatus response.) So, for 
example, if an HTTP client attempted to PUT or DELETE a locked resource,
 the 423 Locked response ought to result in a generic error presented to
 the user.<a class="self" href="#rfc.section.B.p.2">¶</a></p></div><div id="rfc.section.B.p.3"><p>The
 207 Multistatus response is interesting because an HTTP client issuing a
 DELETE request to a collection might interpret a 207 response as a 
success, even though it does not realize the resource is a collection 
and cannot understand that the DELETE operation might have been a 
complete or partial failure. That interpretation isn't entirely 
justified, because a 200-level response indicates that the server 
"received, understood, and accepted" the request, not that the request 
resulted in complete success.<a class="self" href="#rfc.section.B.p.3">¶</a></p></div><div id="rfc.section.B.p.4"><p>One
 option is that a server could treat a DELETE of a collection as an 
atomic operation, and use either 204 No Content in case of success, or 
some appropriate error response (400 or 500 level) for an error. This 
approach would indeed maximize backward compatibility. However, since 
interoperability tests and working group discussions have not turned up 
any instances of HTTP clients issuing a DELETE request against a WebDAV 
collection, this concern is more theoretical than practical. Thus, 
servers are likely to be completely successful at interoperating with 
HTTP clients even if they treat any collection DELETE request as a 
WebDAV request and send a 207 Multi-Status response.<a class="self" href="#rfc.section.B.p.4">¶</a></p></div><div id="rfc.section.B.p.5"><p>In
 general, server implementations are encouraged to use the detailed 
responses and other mechanisms defined in this document rather than make
 changes for theoretical interoperability concerns.<a class="self" href="#rfc.section.B.p.5">¶</a></p></div></section><section id="opaquelocktoken.lock.token.uri.scheme"><h2 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a href="#opaquelocktoken.lock.token.uri.scheme">The 'opaquelocktoken' Scheme and URIs</a></h2><div id="rfc.section.C.p.1"><p>The 'opaquelocktoken' URI scheme was defined in <a href="#RFC2518" id="rfc.xref.RFC2518.9"><cite title="HTTP Extensions for Distributed Authoring -- WEBDAV">[RFC2518]</cite></a>
 (and registered by IANA) in order to create syntactically correct and 
easy-to-generate URIs out of UUIDs, intended to be used as lock tokens 
and to be unique across all resources for all time.<a class="self" href="#rfc.section.C.p.1">¶</a></p></div><div id="rfc.section.C.p.2"><p>An
 opaquelocktoken URI is constructed by concatenating the 
'opaquelocktoken' scheme with a UUID, along with an optional extension. 
Servers can create new UUIDs for each new lock token. If a server wishes
 to reuse UUIDs, the server <em class="bcp14">MUST</em> add an extension, and the algorithm generating the extension <em class="bcp14">MUST</em> guarantee that the same extension will never be used twice with the associated UUID.<a class="self" href="#rfc.section.C.p.2">¶</a></p></div><div id="rfc.figure.u.119"><pre class="inline">  OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension]  
    ; UUID is defined in <a href="https://tools.ietf.org/html/rfc4122#section-3">Section 3</a> of <a href="#RFC4122" id="rfc.xref.RFC4122.5"><cite title="A Universally Unique IDentifier (UUID) URN Namespace">[RFC4122]</cite></a>.  Note that LWS
    ; is not allowed between elements of
    ; this production. 

  Extension = path  
    ; path is defined in <a href="https://tools.ietf.org/html/rfc3986#section-3.3">Section 3.3</a> of <a href="#RFC3986" id="rfc.xref.RFC3986.13"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> 
</pre></div></section><section id="lock-null"><h2 id="rfc.section.D"><a href="#rfc.section.D">D.</a>&nbsp;<a href="#lock-null">Lock-null Resources</a></h2><div id="rfc.section.D.p.1"><p>The
 original WebDAV model for locking unmapped URLs created "lock-null 
resources". This model was over-complicated and some interoperability 
and implementation problems were discovered. The new WebDAV model for 
locking unmapped URLs (see <a href="#lock-unmapped-urls" title="Write Locks and Unmapped URLs">Section&nbsp;7.3</a>)
 creates "locked empty resources". Lock-null resources are deprecated. 
This section discusses the original model briefly because clients <em class="bcp14">MUST</em> be able to handle either model.<a class="self" href="#rfc.section.D.p.1">¶</a></p></div><div id="rfc.section.D.p.2" class="avoidbreakafter"><p>In the original "lock-null resource" model, which is no longer recommended for implementation:<a class="self" href="#rfc.section.D.p.2">¶</a></p></div><div id="rfc.section.D.p.3"><ul><li>A
 lock-null resource sometimes appeared as "Not Found". The server 
responds with a 404 or 405 to any method except for PUT, MKCOL, OPTIONS,
 PROPFIND, LOCK, UNLOCK.</li><li>A lock-null resource does however show up as a member of its parent collection.</li><li>The
 server removes the lock-null resource entirely (its URI becomes 
unmapped) if its lock goes away before it is converted to a regular 
resource. Recall that locks go away not only when they expire or are 
unlocked, but are also removed if a resource is renamed or moved, or if 
any parent collection is renamed or moved.</li><li>The server converts the lock-null resource into a regular resource if a PUT request to the URL is successful.</li><li>The
 server converts the lock-null resource into a collection if a MKCOL 
request to the URL is successful (though interoperability experience 
showed that not all servers followed this requirement).</li><li>Property
 values were defined for DAV:lockdiscovery and DAV:supportedlock 
properties but not necessarily for other properties like 
DAV:getcontenttype.</li></ul></div><div id="rfc.section.D.p.4"><p>Clients
 can easily interoperate both with servers that support the old model 
"lock-null resources" and the recommended model of "locked empty 
resources" by only attempting PUT after a LOCK to an unmapped URL, not 
MKCOL or GET.<a class="self" href="#rfc.section.D.p.4">¶</a></p></div><section id="n-guidance-for-clients-using-lock-to-create-resources"><h3 id="rfc.section.D.1"><a href="#rfc.section.D.1">D.1</a>&nbsp;<a href="#n-guidance-for-clients-using-lock-to-create-resources">Guidance for Clients Using LOCK to Create Resources</a></h3><div id="rfc.section.D.1.p.1"><p>A
 WebDAV client implemented to this specification might find servers that
 create lock-null resources (implemented before this specification using
 <a href="#RFC2518" id="rfc.xref.RFC2518.10"><cite title="HTTP Extensions for Distributed Authoring -- WEBDAV">[RFC2518]</cite></a>)
 as well as servers that create locked empty resources. The response to 
the LOCK request will not indicate what kind of resource was created. 
There are a few techniques that help the client deal with either type.<a class="self" href="#rfc.section.D.1.p.1">¶</a></p></div><div id="rfc.section.D.1.p.2"><ul class="empty"><li>If
 the client wishes to avoid accidentally creating either lock-null or 
empty locked resources, an "If-Match: *" header can be included with 
LOCK requests to prevent the server from creating a new resource.</li><li>If
 a LOCK request creates a resource and the client subsequently wants to 
overwrite that resource using a COPY or MOVE request, the client should 
include an "Overwrite: T" header.</li><li>If a LOCK request creates a 
resource and the client then decides to get rid of that resource, a 
DELETE request is supposed to fail on a lock-null resource and UNLOCK 
should be used instead. But with a locked empty resource, UNLOCK doesn't
 make the resource disappear. Therefore, the client might have to try 
both requests and ignore an error in one of the two requests.</li></ul></div></section></section><section id="n-guidance-for-clients-desiring-to-authenticate"><h2 id="rfc.section.E"><a href="#rfc.section.E">E.</a>&nbsp;<a href="#n-guidance-for-clients-desiring-to-authenticate">Guidance for Clients Desiring to Authenticate</a></h2><div id="rfc.section.E.p.1"><p>Many
 WebDAV clients that have already been implemented have account settings
 (similar to the way email clients store IMAP account settings). Thus, 
the WebDAV client would be able to authenticate with its first couple 
requests to the server, provided it had a way to get the authentication 
challenge from the server with realm name, nonce, and other challenge 
information. Note that the results of some requests might vary according
 to whether or not the client is authenticated -- a PROPFIND might 
return more visible resources if the client is authenticated, yet not 
fail if the client is anonymous.<a class="self" href="#rfc.section.E.p.1">¶</a></p></div><div id="rfc.section.E.p.2"><p>There
 are a number of ways the client might be able to trigger the server to 
provide an authentication challenge. This appendix describes a couple 
approaches that seem particularly likely to work.<a class="self" href="#rfc.section.E.p.2">¶</a></p></div><div id="rfc.section.E.p.3"><p>The
 first approach is to perform a request that ought to require 
authentication. However, it's possible that a server might handle any 
request even without authentication, so to be entirely safe, the client 
could add a conditional header to ensure that even if the request passes
 permissions checks, it's not actually handled by the server. An example
 of following this approach would be to use a PUT request with an 
"If-Match" header with a made-up ETag value. This approach might fail to
 result in an authentication challenge if the server does not test 
authorization before testing conditionals as is required (see <a href="#http-headers" title="HTTP Headers for Use in WebDAV">Section&nbsp;8.5</a>), or if the server does not need to test authorization.<a class="self" href="#rfc.section.E.p.3">¶</a></p></div><div id="rfc.section.E.p.4"><p>Example - forcing auth challenge with write request<a class="self" href="#rfc.section.E.p.4">¶</a></p></div><div id="rfc.figure.u.120"><p>&gt;&gt;Request</p><pre class="text2">  PUT /forceauth.txt HTTP/1.1 
  Host: www.example.com 
  If-Match: "xxx"
  Content-Type: text/plain
  Content-Length: 0
</pre></div><div id="rfc.section.E.p.5" class="avoidbreakafter"><p>The second approach is to use an Authorization header (defined in <a href="#RFC2617" id="rfc.xref.RFC2617.2"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>),
 which is likely to be rejected by the server but which will then prompt
 a proper authentication challenge. For example, the client could start 
with a PROPFIND request containing an Authorization header containing a 
made-up Basic userid:password string or with actual plausible 
credentials. This approach relies on the server responding with a "401 
Unauthorized" along with a challenge if it receives an Authorization 
header with an unrecognized username, invalid password, or if it doesn't
 even handle Basic authentication. This seems likely to work because of 
the requirements of RFC 2617:<a class="self" href="#rfc.section.E.p.5">¶</a></p></div><div id="rfc.section.E.p.6"><p>"If the origin server does not wish to accept the credentials sent with a request, it <em class="bcp14">SHOULD</em> return a 401 (Unauthorized) response. The response <em class="bcp14">MUST</em> include a WWW-Authenticate header field containing at least one (possibly new) challenge applicable to the requested resource."<a class="self" href="#rfc.section.E.p.6">¶</a></p></div><div id="rfc.section.E.p.7"><p>There's
 a slight problem with implementing that recommendation in some cases, 
because some servers do not even have challenge information for certain 
resources. Thus, when there's no way to authenticate to a resource or 
the resource is entirely publicly available over all accepted methods, 
the server <em class="bcp14">MAY</em> ignore the Authorization header, and the client will presumably try again later.<a class="self" href="#rfc.section.E.p.7">¶</a></p></div><div id="rfc.section.E.p.8"><p>Example - forcing auth challenge with Authorization header<a class="self" href="#rfc.section.E.p.8">¶</a></p></div><div id="rfc.figure.u.121"><p>&gt;&gt;Request</p><pre class="text2">  PROPFIND /docs/ HTTP/1.1 
  Host: www.example.com 
  Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
  Content-type: application/xml; charset="utf-8" 
  Content-Length: xxxx 
          
  [body omitted]
</pre></div></section><section id="n-summary-of-changes-from-rfc-2518"><h2 id="rfc.section.F"><a href="#rfc.section.F">F.</a>&nbsp;<a href="#n-summary-of-changes-from-rfc-2518">Summary of Changes from RFC 2518</a></h2><div id="rfc.section.F.p.1"><p>This
 section lists major changes between this document and RFC 2518, 
starting with those that are likely to result in implementation changes.
 Servers will advertise support for all changes in this specification by
 returning the compliance class "3" in the DAV response header (see 
Sections <a href="#HEADER_DAV" title="DAV Header">10.1</a> and <a href="#compliance-class-3" title="Class 3">18.3</a>).<a class="self" href="#rfc.section.F.p.1">¶</a></p></div><section id="n-changes-for-both-client-and-server-implementations"><h3 id="rfc.section.F.1"><a href="#rfc.section.F.1">F.1</a>&nbsp;<a href="#n-changes-for-both-client-and-server-implementations">Changes for Both Client and Server Implementations</a></h3><div id="rfc.section.F.1.p.1"><p><b>Collections and Namespace Operations</b> <a class="self" href="#rfc.section.F.1.p.1">¶</a></p><ul><li>The semantics of PROPFIND 'allprop' (<a href="#METHOD_PROPFIND" title="PROPFIND Method">Section&nbsp;9.1</a>)
 have been relaxed so that servers return results including, at a 
minimum, the live properties defined in this specification, but not 
necessarily return other live properties. The 'allprop' directive 
therefore means something more like "return all properties that are 
supposed to be returned when 'allprop' is requested" -- a set of 
properties that may include custom properties and properties defined in 
other specifications if those other specifications so require. Related 
to this, 'allprop' requests can now be extended with the 'include' 
syntax to include specific named properties, thereby avoiding additional
 requests due to changed 'allprop' semantics.</li><li>Servers are now 
allowed to reject PROPFIND requests with Depth:Infinity. Clients that 
used this will need to be able to do a series of Depth:1 requests 
instead.</li><li>Multi-Status response bodies now can transport the 
value of HTTP's Location response header in the new 'location' element. 
Clients may use this to avoid additional roundtrips to the server when 
there is a 'response' element with a 3xx status (see <a href="#ELEMENT_response" title="response XML Element">Section&nbsp;14.24</a>).</li><li>The
 definition of COPY has been relaxed so that it doesn't require servers 
to first delete the target resources anymore (this was a known 
incompatibility with <a href="#RFC3253" id="rfc.xref.RFC3253.8"><cite title="Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)">[RFC3253]</cite></a>). See <a href="#METHOD_COPY" title="COPY Method">Section&nbsp;9.8</a>.</li></ul></div><div id="rfc.section.F.1.p.2"><p><b>Headers and Marshalling</b> <a class="self" href="#rfc.section.F.1.p.2">¶</a></p><ul><li>The Destination and If request headers now allow absolute paths in addition to full URIs (see <a href="#url-handling" title="URL Handling">Section&nbsp;8.3</a>).
 This may be useful for clients operating through a reverse proxy that 
does rewrite the Host request header, but not WebDAV-specific headers.</li><li>This specification adopts the error marshalling extensions and the "precondition/postcondition" terminology defined in <a href="#RFC3253" id="rfc.xref.RFC3253.9"><cite title="Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)">[RFC3253]</cite></a> (see <a href="#precondition.postcondition.xml.elements" title="Precondition/Postcondition XML Elements">Section&nbsp;16</a>). Related to that, it adds the "error" XML element inside multistatus response bodies (see <a href="#ELEMENT_error" title="error XML Element">Section&nbsp;14.5</a>, however note that it uses a format different from the one recommended in RFC 3253).</li><li>Senders and recipients are now required to support the UTF-16 character encoding in XML message bodies (see <a href="#internationalization.considerations" title="Internationalization Considerations">Section&nbsp;19</a>).</li><li>Clients
 are now required to send the Depth header on PROPFIND requests, 
although servers are still encouraged to support clients that don't.</li></ul></div><div id="rfc.section.F.1.p.3"><p><b>Locking</b> <a class="self" href="#rfc.section.F.1.p.3">¶</a></p><ul><li>RFC
 2518's concept of "lock-null resources" (LNRs) has been replaced by a 
simplified approach, the "locked empty resources" (see <a href="#lock-unmapped-urls" title="Write Locks and Unmapped URLs">Section&nbsp;7.3</a>).
 There are some aspects of lock-null resources clients cannot rely on 
anymore, namely, the ability to use them to create a locked collection 
or the fact that they disappear upon UNLOCK when no PUT or MKCOL request
 was issued. Note that servers are still allowed to implement LNRs as 
per RFC 2518.</li><li>There is no implicit refresh of locks anymore. Locks are only refreshed upon explicit request (see <a href="#refreshing-locks" title="Refreshing Locks">Section&nbsp;9.10.2</a>).</li><li>Clarified that the DAV:owner value supplied in the LOCK request must be preserved by the server just like a dead property (<a href="#ELEMENT_owner" title="owner XML Element">Section&nbsp;14.17</a>). Also added the DAV:lockroot element (<a href="#ELEMENT_lockroot" title="lockroot XML Element">Section&nbsp;14.12</a>), which allows clients to discover the root of lock.</li></ul></div></section><section id="n-changes-for-server-implementations"><h3 id="rfc.section.F.2"><a href="#rfc.section.F.2">F.2</a>&nbsp;<a href="#n-changes-for-server-implementations">Changes for Server Implementations</a></h3><div id="rfc.section.F.2.p.1"><p><b>Collections and Namespace Operations</b> <a class="self" href="#rfc.section.F.2.p.1">¶</a></p><ul><li>Due
 to interoperability problems, allowable formats for contents of 'href' 
elements in multistatus responses have been limited (see <a href="#url-handling" title="URL Handling">Section&nbsp;8.3</a>).</li><li id="ELEMENT_propertybehaviour"><span id="rfc.iref.p.6"></span>
 Due to lack of implementation, support for the 'propertybehavior' 
request body for COPY and MOVE has been removed. Instead, requirements 
for property preservation have been clarified (see Sections <a href="#METHOD_COPY" title="COPY Method">9.8</a> and <a href="#METHOD_MOVE" title="MOVE Method">9.9</a>).</li></ul></div><div id="rfc.section.F.2.p.2"><p><b>Properties</b> <a class="self" href="#rfc.section.F.2.p.2">¶</a></p><ul><li>Strengthened
 server requirements for storage of property values, in particular 
persistence of language information (xml:lang), whitespace, and XML 
namespace information (see <a href="#property_values" title="Property Values">Section&nbsp;4.3</a>).</li><li>Clarified
 requirements on which properties should be writable by the client; in 
particular, setting "DAV:displayname" should be supported by servers 
(see <a href="#dav.properties" title="DAV Properties">Section&nbsp;15</a>).</li><li>Only 'rfc1123-date' productions are legal as values for DAV:getlastmodified (see <a href="#PROPERTY_getlastmodified" title="getlastmodified Property">Section&nbsp;15.7</a>).</li></ul></div><div id="rfc.section.F.2.p.3"><p><b>Headers and Marshalling</b> <a class="self" href="#rfc.section.F.2.p.3">¶</a></p><ul><li>Servers are now required to do authorization checks before processing conditional headers (see <a href="#http-headers" title="HTTP Headers for Use in WebDAV">Section&nbsp;8.5</a>).</li></ul></div><div id="rfc.section.F.2.p.4"><p><b>Locking</b> <a class="self" href="#rfc.section.F.2.p.4">¶</a></p><ul><li>Strengthened requirement to check identity of lock creator when accessing locked resources (see <a href="#lock-creator" title="Lock Creator and Privileges">Section&nbsp;6.4</a>). Clients should be aware that lock tokens returned to other principals can only be used to break a lock, if at all.</li><li><a href="https://tools.ietf.org/html/rfc2518#section-8.10.4">Section 8.10.4</a> of <a href="#RFC2518" id="rfc.xref.RFC2518.11"><cite title="HTTP Extensions for Distributed Authoring -- WEBDAV">[RFC2518]</cite></a> incorrectly required servers to return a 409 status where a 207 status was really appropriate. This has been corrected (<a href="#METHOD_LOCK" title="LOCK Method">Section&nbsp;9.10</a>).</li></ul></div></section><section id="n-other-changes"><h3 id="rfc.section.F.3"><a href="#rfc.section.F.3">F.3</a>&nbsp;<a href="#n-other-changes">Other Changes</a></h3><div id="rfc.section.F.3.p.1"><p>The definition of collection state has been fixed so it doesn't vary anymore depending on the Request-URI (see <a href="#collection.resources" title="Collection Resources">Section&nbsp;5.2</a>).<a class="self" href="#rfc.section.F.3.p.1">¶</a></p></div><div id="PROPERTY_source"><div id="rfc.section.F.3.p.2"><p><span id="rfc.iref.d.10"></span> <span id="rfc.iref.p.7"></span> The DAV:source property introduced in <a href="https://tools.ietf.org/html/rfc2518#section-4.6">Section 4.6</a> of <a href="#RFC2518" id="rfc.xref.RFC2518.12"><cite title="HTTP Extensions for Distributed Authoring -- WEBDAV">[RFC2518]</cite></a> was removed due to lack of implementation experience.<a class="self" href="#rfc.section.F.3.p.2">¶</a></p></div></div><div id="rfc.section.F.3.p.3"><p>The
 DAV header now allows non-IETF extensions through URIs in addition to 
compliance class tokens. It also can now be used in requests, although 
this specification does not define any associated semantics for the 
compliance classes defined in here (see <a href="#HEADER_DAV" title="DAV Header">Section&nbsp;10.1</a>).<a class="self" href="#rfc.section.F.3.p.3">¶</a></p></div><div id="rfc.section.F.3.p.4"><p>In RFC 2518, the definition of the Depth header (<a href="https://tools.ietf.org/html/rfc2518#section-9.2" id="rfc.xref.RFC2518.13">Section 9.2</a>)
 required that, by default, request headers would be applied to each 
resource in scope. Based on implementation experience, the default has 
now been reversed (see <a href="#HEADER_Depth" title="Depth Header">Section&nbsp;10.2</a>).<a class="self" href="#rfc.section.F.3.p.4">¶</a></p></div><div id="HEADER_Status-URI"><div id="rfc.section.F.3.p.5"><p>The definitions of HTTP status code 102 (<a href="#RFC2518" id="rfc.xref.RFC2518.14"><cite title="HTTP Extensions for Distributed Authoring -- WEBDAV">[RFC2518]</cite></a>, <a href="https://tools.ietf.org/html/rfc2518#section-10.1">Section 10.1</a>) and the Status-URI response header (<a href="https://tools.ietf.org/html/rfc2518#section-9.7" id="rfc.xref.RFC2518.15">Section 9.7</a>) have been removed due to lack of implementation.<a class="self" href="#rfc.section.F.3.p.5">¶</a></p></div></div><div id="rfc.section.F.3.p.6"><p>The
 TimeType format used in the Timeout request header and the "timeout" 
XML element used to be extensible. Now, only the two formats defined by 
this specification are allowed (see <a href="#HEADER_Timeout" title="Timeout Request Header">Section&nbsp;10.7</a>).<a class="self" href="#rfc.section.F.3.p.6">¶</a></p></div></section></section><section id="rfc.index"><h2><a href="#rfc.index">Index</a></h2><p class="noprint"><a href="#rfc.index.1">1</a> <a href="#rfc.index.2">2</a> <a href="#rfc.index.4">4</a> <a href="#rfc.index.5">5</a> <a href="#rfc.index.A">A</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.D">D</a> <a href="#rfc.index.E">E</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.L">L</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.O">O</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.T">T</a> <a href="#rfc.index.U">U</a> <a href="#rfc.index.W">W</a> </p><div class="print2col"><ul class="ind"><li><a id="rfc.index.1" href="#rfc.index.1"><b>1</b></a><ul><li>102 Processing (status code)&nbsp;&nbsp;<a href="#rfc.iref.1.1">21.4</a></li></ul></li><li><a id="rfc.index.2" href="#rfc.index.2"><b>2</b></a><ul><li>207 Multi-Status (status code)&nbsp;&nbsp;<a href="#rfc.section.11.1"><b>11.1</b></a></li></ul></li><li><a id="rfc.index.4" href="#rfc.index.4"><b>4</b></a><ul><li>412 Precondition Failed (status code)&nbsp;&nbsp;<a href="#rfc.section.12.1">12.1</a></li><li>414 Request-URI Too Long (status code)&nbsp;&nbsp;<a href="#rfc.section.12.2">12.2</a></li><li>422 Unprocessable Entity (status code)&nbsp;&nbsp;<a href="#rfc.section.11.2"><b>11.2</b></a></li><li>423 Locked (status code)&nbsp;&nbsp;<a href="#rfc.section.11.3"><b>11.3</b></a></li><li>424 Failed Dependency (status code)&nbsp;&nbsp;<a href="#rfc.section.11.4"><b>11.4</b></a></li></ul></li><li><a id="rfc.index.5" href="#rfc.index.5"><b>5</b></a><ul><li>507 Insufficient Storage (status code)&nbsp;&nbsp;<a href="#rfc.section.11.5"><b>11.5</b></a></li></ul></li><li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul><li>activelock&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.14.1">14.1</a></li></ul></li><li>allprop&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.14.2">14.2</a></li></ul></li></ul></li><li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul><li>Collection&nbsp;&nbsp;<a href="#rfc.iref.c.1"><b>3</b></a></li><li>collection&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.14.3">14.3</a></li></ul></li><li>Condition Names&nbsp;&nbsp;<ul><li>DAV:cannot-modify-protected-property (pre)&nbsp;&nbsp;<a href="#rfc.iref.c.8"><b>16</b></a></li><li>DAV:lock-token-matches-request-uri (pre)&nbsp;&nbsp;<a href="#rfc.iref.c.2"><b>16</b></a></li><li>DAV:lock-token-submitted (pre)&nbsp;&nbsp;<a href="#rfc.iref.c.3"><b>16</b></a></li><li>DAV:no-conflicting-lock (pre)&nbsp;&nbsp;<a href="#rfc.iref.c.4"><b>16</b></a></li><li>DAV:no-external-entities (pre)&nbsp;&nbsp;<a href="#rfc.iref.c.5"><b>16</b></a></li><li>DAV:preserved-live-properties (pre)&nbsp;&nbsp;<a href="#rfc.iref.c.6"><b>16</b></a></li><li>DAV:propfind-finite-depth (pre)&nbsp;&nbsp;<a href="#rfc.iref.c.7"><b>16</b></a></li></ul></li><li>COPY method&nbsp;&nbsp;<a href="#rfc.section.9.8"><b>9.8</b></a></li></ul></li><li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul><li>DAV header&nbsp;&nbsp;<a href="#rfc.section.10.1"><b>10.1</b></a><ul><li>compliance class '1'&nbsp;&nbsp;<a href="#rfc.section.18.1"><b>18.1</b></a></li><li>compliance class '2'&nbsp;&nbsp;<a href="#rfc.section.18.2"><b>18.2</b></a></li><li>compliance class '3'&nbsp;&nbsp;<a href="#rfc.section.18.3"><b>18.3</b></a></li></ul></li><li>DAV URI scheme&nbsp;&nbsp;<a href="#rfc.iref.d.9"><b>21.1</b></a></li><li>DAV:cannot-modify-protected-property precondition&nbsp;&nbsp;<a href="#rfc.iref.d.8"><b>16</b></a></li><li>DAV:collection resource type&nbsp;&nbsp;<a href="#rfc.section.14.3"><b>14.3</b></a></li><li>DAV:creationdate property&nbsp;&nbsp;<a href="#rfc.section.15.1"><b>15.1</b></a></li><li>DAV:displayname property&nbsp;&nbsp;<a href="#rfc.section.15.2"><b>15.2</b></a></li><li>DAV:getcontentlanguage property&nbsp;&nbsp;<a href="#rfc.section.15.3"><b>15.3</b></a></li><li>DAV:getcontentlength property&nbsp;&nbsp;<a href="#rfc.section.15.4"><b>15.4</b></a></li><li>DAV:getcontenttype property&nbsp;&nbsp;<a href="#rfc.section.15.5"><b>15.5</b></a></li><li>DAV:getetag property&nbsp;&nbsp;<a href="#rfc.section.15.6"><b>15.6</b></a></li><li>DAV:getlastmodified property&nbsp;&nbsp;<a href="#rfc.section.15.7"><b>15.7</b></a></li><li>DAV:lock-token-matches-request-uri precondition&nbsp;&nbsp;<a href="#rfc.iref.d.2"><b>16</b></a></li><li>DAV:lock-token-submitted precondition&nbsp;&nbsp;<a href="#rfc.iref.d.3"><b>16</b></a></li><li>DAV:lockdiscovery property&nbsp;&nbsp;<a href="#rfc.section.15.8"><b>15.8</b></a></li><li>DAV:no-conflicting-lock precondition&nbsp;&nbsp;<a href="#rfc.iref.d.4"><b>16</b></a></li><li>DAV:no-external-entities precondition&nbsp;&nbsp;<a href="#rfc.iref.d.5"><b>16</b></a></li><li>DAV:preserved-live-properties precondition&nbsp;&nbsp;<a href="#rfc.iref.d.6"><b>16</b></a></li><li>DAV:propfind-finite-depth precondition&nbsp;&nbsp;<a href="#rfc.iref.d.7"><b>16</b></a></li><li>DAV:resourcetype property&nbsp;&nbsp;<a href="#rfc.section.15.9"><b>15.9</b></a></li><li>DAV:source property&nbsp;&nbsp;<a href="#rfc.iref.d.10">F.3</a></li><li>DAV:supportedlock property&nbsp;&nbsp;<a href="#rfc.section.15.10"><b>15.10</b></a></li><li>Dead Property&nbsp;&nbsp;<a href="#rfc.iref.d.1"><b>3</b></a></li><li>DELETE method&nbsp;&nbsp;<a href="#rfc.section.9.6"><b>9.6</b></a></li><li>depth&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.14.4">14.4</a></li></ul></li><li>Depth header&nbsp;&nbsp;<a href="#rfc.section.10.2"><b>10.2</b></a></li><li>Destination header&nbsp;&nbsp;<a href="#rfc.section.10.3"><b>10.3</b></a></li></ul></li><li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul><li>error&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.14.5">14.5</a></li></ul></li><li>exclusive&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.14.6">14.6</a></li></ul></li></ul></li><li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul><li>Grammar&nbsp;&nbsp;<ul><li>Simple-ref&nbsp;&nbsp;<a href="#rfc.iref.g.1">8.3</a></li></ul></li></ul></li><li><a id="rfc.index.H" href="#rfc.index.H"><b>H</b></a><ul><li>Headers&nbsp;&nbsp;<ul><li>DAV&nbsp;&nbsp;<a href="#rfc.section.10.1"><b>10.1</b></a></li><li>Depth&nbsp;&nbsp;<a href="#rfc.section.10.2"><b>10.2</b></a></li><li>Destination&nbsp;&nbsp;<a href="#rfc.section.10.3"><b>10.3</b></a></li><li>If&nbsp;&nbsp;<a href="#rfc.section.10.4"><b>10.4</b></a></li><li>Lock-Token&nbsp;&nbsp;<a href="#rfc.section.10.5"><b>10.5</b></a></li><li>Overwrite&nbsp;&nbsp;<a href="#rfc.section.10.6"><b>10.6</b></a></li><li>Timeout&nbsp;&nbsp;<a href="#rfc.section.10.7"><b>10.7</b></a></li></ul></li><li>href&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.14.7">14.7</a></li></ul></li></ul></li><li><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul><li>If header&nbsp;&nbsp;<a href="#rfc.section.10.4"><b>10.4</b></a></li><li>include&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.14.8">14.8</a></li></ul></li><li>Internal Member&nbsp;&nbsp;<a href="#rfc.iref.i.1"><b>3</b></a></li><li>Internal Member URL&nbsp;&nbsp;<a href="#rfc.iref.i.2"><b>3</b></a></li></ul></li><li><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul><li>Live Property&nbsp;&nbsp;<a href="#rfc.iref.l.1"><b>3</b></a></li><li>location&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.14.9">14.9</a></li></ul></li><li>LOCK method&nbsp;&nbsp;<a href="#rfc.section.9.10"><b>9.10</b></a></li><li>Lock-Token header&nbsp;&nbsp;<a href="#rfc.section.10.5"><b>10.5</b></a></li><li>lockentry&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.14.10">14.10</a></li></ul></li><li>lockinfo&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.14.11">14.11</a></li></ul></li><li>lockroot&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.14.12">14.12</a></li></ul></li><li>lockscope&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.14.13">14.13</a></li></ul></li><li>locktoken&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.14.14">14.14</a></li></ul></li><li>locktype&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.14.15">14.15</a></li></ul></li></ul></li><li><a id="rfc.index.M" href="#rfc.index.M"><b>M</b></a><ul><li>Member&nbsp;&nbsp;<a href="#rfc.iref.m.1"><b>3</b></a></li><li>Member URL&nbsp;&nbsp;<a href="#rfc.iref.m.2"><b>3</b></a></li><li>Methods&nbsp;&nbsp;<ul><li>COPY&nbsp;&nbsp;<a href="#rfc.section.9.8"><b>9.8</b></a></li><li>DELETE&nbsp;&nbsp;<a href="#rfc.section.9.6"><b>9.6</b></a></li><li>LOCK&nbsp;&nbsp;<a href="#rfc.section.9.10"><b>9.10</b></a></li><li>MKCOL&nbsp;&nbsp;<a href="#rfc.section.9.3"><b>9.3</b></a></li><li>MOVE&nbsp;&nbsp;<a href="#rfc.section.9.9"><b>9.9</b></a></li><li>PROPFIND&nbsp;&nbsp;<a href="#rfc.section.9.1"><b>9.1</b></a></li><li>PROPPATCH&nbsp;&nbsp;<a href="#rfc.section.9.2"><b>9.2</b></a></li><li>PUT&nbsp;&nbsp;<a href="#rfc.section.9.7"><b>9.7</b></a></li><li>UNLOCK&nbsp;&nbsp;<a href="#rfc.section.9.11"><b>9.11</b></a></li></ul></li><li>MKCOL method&nbsp;&nbsp;<a href="#rfc.section.9.3"><b>9.3</b></a></li><li>MOVE method&nbsp;&nbsp;<a href="#rfc.section.9.9"><b>9.9</b></a></li><li>multistatus&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.14.16">14.16</a></li></ul></li></ul></li><li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul><li>opaquelocktoken URI scheme&nbsp;&nbsp;<a href="#rfc.section.C"><b>C</b></a></li><li>Overwrite header&nbsp;&nbsp;<a href="#rfc.section.10.6"><b>10.6</b></a></li><li>owner&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.14.17">14.17</a></li></ul></li></ul></li><li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul><li>Path Segment&nbsp;&nbsp;<a href="#rfc.iref.p.1"><b>3</b></a></li><li>Postcondition&nbsp;&nbsp;<a href="#rfc.iref.p.5"><b>16</b></a></li><li>Precondition&nbsp;&nbsp;<a href="#rfc.iref.p.4"><b>16</b></a></li><li>Principal&nbsp;&nbsp;<a href="#rfc.iref.p.3"><b>3</b></a></li><li>prop&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.14.18">14.18</a></li></ul></li><li>Properties&nbsp;&nbsp;<ul><li>DAV:creationdate&nbsp;&nbsp;<a href="#rfc.section.15.1"><b>15.1</b></a></li><li>DAV:displayname&nbsp;&nbsp;<a href="#rfc.section.15.2"><b>15.2</b></a></li><li>DAV:getcontentlanguage&nbsp;&nbsp;<a href="#rfc.section.15.3"><b>15.3</b></a></li><li>DAV:getcontentlength&nbsp;&nbsp;<a href="#rfc.section.15.4"><b>15.4</b></a></li><li>DAV:getcontenttype&nbsp;&nbsp;<a href="#rfc.section.15.5"><b>15.5</b></a></li><li>DAV:getetag&nbsp;&nbsp;<a href="#rfc.section.15.6"><b>15.6</b></a></li><li>DAV:getlastmodified&nbsp;&nbsp;<a href="#rfc.section.15.7"><b>15.7</b></a></li><li>DAV:lockdiscovery&nbsp;&nbsp;<a href="#rfc.section.15.8"><b>15.8</b></a></li><li>DAV:resourcetype&nbsp;&nbsp;<a href="#rfc.section.15.9"><b>15.9</b></a></li><li>DAV:source&nbsp;&nbsp;<a href="#rfc.iref.p.7">F.3</a></li><li>DAV:supportedlock&nbsp;&nbsp;<a href="#rfc.section.15.10"><b>15.10</b></a></li></ul></li><li>Property&nbsp;&nbsp;<a href="#rfc.iref.p.2"><b>3</b></a></li><li>propertybehaviour&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.iref.p.6">F.2</a></li></ul></li><li>propertyupdate&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.14.19">14.19</a></li></ul></li><li>propfind&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.14.20">14.20</a></li></ul></li><li>PROPFIND method&nbsp;&nbsp;<a href="#rfc.section.9.1"><b>9.1</b></a></li><li>propname&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.14.21">14.21</a></li></ul></li><li>PROPPATCH method&nbsp;&nbsp;<a href="#rfc.section.9.2"><b>9.2</b></a></li><li>propstat&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.14.22">14.22</a></li></ul></li><li>PUT method&nbsp;&nbsp;<a href="#rfc.section.9.7"><b>9.7</b></a></li></ul></li><li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul><li><em>REC-XML</em>&nbsp;&nbsp;<a href="#rfc.xref.REC-XML.1">1</a>, <a href="#rfc.xref.REC-XML.2">8.2</a>, <a href="#rfc.xref.REC-XML.3">8.2</a>, <a href="#rfc.xref.REC-XML.4">14</a>, <a href="#rfc.xref.REC-XML.5">15</a>, <a href="#rfc.xref.REC-XML.6">19</a>, <a href="#rfc.xref.REC-XML.7">20.6</a>, <a href="#rfc.xref.REC-XML.8">20.6</a>, <a href="#REC-XML"><b>25.1</b></a><ul><li><em>Section 4.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.REC-XML.7">20.6</a>, <a href="#rfc.xref.REC-XML.8">20.6</a></li></ul></li><li><em>REC-XML-INFOSET</em>&nbsp;&nbsp;<a href="#rfc.xref.REC-XML-INFOSET.1">4.3</a>, <a href="#REC-XML-INFOSET"><b>25.1</b></a></li><li><em>REC-XML-NAMES</em>&nbsp;&nbsp;<a href="#rfc.xref.REC-XML-NAMES.1">8.2</a>, <a href="#rfc.xref.REC-XML-NAMES.2">17</a>, <a href="#REC-XML-NAMES"><b>25.1</b></a></li><li>remove&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.14.23">14.23</a></li></ul></li><li>Resource Types&nbsp;&nbsp;<ul><li>DAV:collection&nbsp;&nbsp;<a href="#rfc.section.14.3"><b>14.3</b></a></li></ul></li><li>response&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.14.24">14.24</a></li></ul></li><li>responsedescription&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.14.25">14.25</a></li></ul></li><li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">2</a>, <a href="#RFC2119"><b>25.1</b></a></li><li><em>RFC2277</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2277.1">19</a>, <a href="#RFC2277"><b>25.1</b></a></li><li><em>RFC2291</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2291.1">1</a>, <a href="#rfc.xref.RFC2291.2">1</a>, <a href="#RFC2291"><b>25.2</b></a></li><li><em>RFC2518</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2518.1">7.3</a>, <a href="#rfc.xref.RFC2518.2">8.3</a>, <a href="#rfc.xref.RFC2518.3">13.2</a>, <a href="#rfc.xref.RFC2518.4">15.2</a>, <a href="#rfc.xref.RFC2518.5">15.3</a>, <a href="#rfc.xref.RFC2518.6">18.3</a>, <a href="#rfc.xref.RFC2518.7">21.1</a>, <a href="#rfc.xref.RFC2518.8">21.4</a>, <a href="#RFC2518"><b>25.2</b></a>, <a href="#rfc.xref.RFC2518.9">C</a>, <a href="#rfc.xref.RFC2518.10">D.1</a>, <a href="#rfc.xref.RFC2518.11">F.2</a>, <a href="#rfc.xref.RFC2518.12">F.3</a>, <a href="#rfc.xref.RFC2518.13">F.3</a>, <a href="#rfc.xref.RFC2518.14">F.3</a>, <a href="#rfc.xref.RFC2518.15">F.3</a><ul><li><em>Section 4.6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2518.12">F.3</a></li><li><em>Section 8.10.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2518.11">F.2</a></li><li><em>Section 9.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2518.13">F.3</a></li><li><em>Section 9.7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2518.15">F.3</a></li><li><em>Section 10.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2518.14">F.3</a></li></ul></li><li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">2</a>, <a href="#rfc.xref.RFC2616.2">2</a>, <a href="#rfc.xref.RFC2616.3">5.1</a>, <a href="#rfc.xref.RFC2616.4">7.3</a>, <a href="#rfc.xref.RFC2616.5">8.3</a>, <a href="#rfc.xref.RFC2616.6">8.5</a>, <a href="#rfc.xref.RFC2616.7">8.5</a>, <a href="#rfc.xref.RFC2616.8">8.6</a>, <a href="#rfc.xref.RFC2616.9">8.8</a>, <a href="#rfc.xref.RFC2616.10">8.8</a>, <a href="#rfc.xref.RFC2616.11">8.8</a>, <a href="#rfc.xref.RFC2616.12">9.1</a>, <a href="#rfc.xref.RFC2616.13">9.2</a>, <a href="#rfc.xref.RFC2616.14">9.3</a>, <a href="#rfc.xref.RFC2616.15">9.4</a>, <a href="#rfc.xref.RFC2616.16">9.6</a>, <a href="#rfc.xref.RFC2616.17">9.8</a>, <a href="#rfc.xref.RFC2616.18">9.9</a>, <a href="#rfc.xref.RFC2616.19">9.10</a>, <a href="#rfc.xref.RFC2616.20">9.11</a>, <a href="#rfc.xref.RFC2616.21">10.1</a>, <a href="#rfc.xref.RFC2616.22">10.1</a>, <a href="#rfc.xref.RFC2616.23">10.4</a>, <a href="#rfc.xref.RFC2616.24">10.4.2</a>, <a href="#rfc.xref.RFC2616.25">10.4.2</a>, <a href="#rfc.xref.RFC2616.26">10.4.4</a>, <a href="#rfc.xref.RFC2616.27">10.6</a>, <a href="#rfc.xref.RFC2616.28">11</a>, <a href="#rfc.xref.RFC2616.29">13</a>, <a href="#rfc.xref.RFC2616.30">14.9</a>, <a href="#rfc.xref.RFC2616.31">14.28</a>, <a href="#rfc.xref.RFC2616.32">15</a>, <a href="#rfc.xref.RFC2616.33">15.3</a>, <a href="#rfc.xref.RFC2616.34">15.3</a>, <a href="#rfc.xref.RFC2616.35">15.4</a>, <a href="#rfc.xref.RFC2616.36">15.5</a>, <a href="#rfc.xref.RFC2616.37">15.5</a>, <a href="#rfc.xref.RFC2616.38">15.6</a>, <a href="#rfc.xref.RFC2616.39">15.6</a>, <a href="#rfc.xref.RFC2616.40">15.6</a>, <a href="#rfc.xref.RFC2616.41">15.7</a>, <a href="#rfc.xref.RFC2616.42">15.7</a>, <a href="#rfc.xref.RFC2616.43">15.7</a>, <a href="#rfc.xref.RFC2616.44">18</a>, <a href="#rfc.xref.RFC2616.45">20</a>, <a href="#RFC2616"><b>25.1</b></a><ul><li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">2</a></li><li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.2">2</a>, <a href="#rfc.xref.RFC2616.21">10.1</a></li><li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.5">8.3</a></li><li><em>Section 3.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.42">15.7</a></li><li><em>Section 3.7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.37">15.5</a></li><li><em>Section 3.10</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.34">15.3</a></li><li><em>Section 3.11</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.24">10.4.2</a>, <a href="#rfc.xref.RFC2616.39">15.6</a>, <a href="#rfc.xref.RFC2616.40">15.6</a></li><li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.25">10.4.2</a>, <a href="#rfc.xref.RFC2616.32">15</a></li><li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.31">14.28</a></li><li><em>Section 9.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.12">9.1</a>, <a href="#rfc.xref.RFC2616.13">9.2</a>, <a href="#rfc.xref.RFC2616.14">9.3</a>, <a href="#rfc.xref.RFC2616.17">9.8</a>, <a href="#rfc.xref.RFC2616.18">9.9</a>, <a href="#rfc.xref.RFC2616.19">9.10</a>, <a href="#rfc.xref.RFC2616.20">9.11</a></li><li><em>Section 9.7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.16">9.6</a></li><li><em>Section 10</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.29">13</a></li><li><em>Section 13.3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.8">8.6</a>, <a href="#rfc.xref.RFC2616.26">10.4.4</a></li><li><em>Section 14.12</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.33">15.3</a></li><li><em>Section 14.13</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.35">15.4</a></li><li><em>Section 14.17</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.36">15.5</a></li><li><em>Section 14.18</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.6">8.5</a></li><li><em>Section 14.19</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.10">8.8</a>, <a href="#rfc.xref.RFC2616.38">15.6</a></li><li><em>Section 14.24</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.23">10.4</a></li><li><em>Section 14.26</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.4">7.3</a></li><li><em>Section 14.29</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.11">8.8</a>, <a href="#rfc.xref.RFC2616.41">15.7</a></li><li><em>Section 14.30</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.30">14.9</a></li></ul></li><li><em>RFC2617</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2617.1">20.1</a>, <a href="#RFC2617"><b>25.1</b></a>, <a href="#rfc.xref.RFC2617.2">E</a></li><li><em>RFC2781</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2781.1">19</a>, <a href="#RFC2781"><b>25.2</b></a></li><li><em>RFC3023</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3023.1">19</a>, <a href="#rfc.xref.RFC3023.2">19</a>, <a href="#rfc.xref.RFC3023.3">20</a>, <a href="#rfc.xref.RFC3023.4">20.6</a>, <a href="#RFC3023"><b>25.2</b></a></li><li><em>RFC3253</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3253.1">1</a>, <a href="#rfc.xref.RFC3253.2">8.7</a>, <a href="#rfc.xref.RFC3253.3">9.1</a>, <a href="#rfc.xref.RFC3253.4">9.1.6</a>, <a href="#rfc.xref.RFC3253.5">9.8.4</a>, <a href="#rfc.xref.RFC3253.6">16</a>, <a href="#rfc.xref.RFC3253.7">16</a>, <a href="#RFC3253"><b>25.2</b></a>, <a href="#rfc.xref.RFC3253.8">F.1</a>, <a href="#rfc.xref.RFC3253.9">F.1</a><ul><li><em>Section 1.6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3253.2">8.7</a></li><li><em>Section 3.12</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3253.7">16</a></li></ul></li><li><em>RFC3339</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3339.1">15.1</a>, <a href="#rfc.xref.RFC3339.2">15.1</a>, <a href="#RFC3339"><b>25.1</b></a><ul><li><em>Section 5.6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3339.2">15.1</a></li></ul></li><li><em>RFC3629</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3629.1">19</a>, <a href="#RFC3629"><b>25.1</b></a></li><li><em>RFC3648</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3648.1">16</a>, <a href="#RFC3648"><b>25.2</b></a></li><li><em>RFC3744</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3744.1">6.4</a>, <a href="#rfc.xref.RFC3744.2">9.1</a>, <a href="#rfc.xref.RFC3744.3">16</a>, <a href="#rfc.xref.RFC3744.4">16</a>, <a href="#RFC3744"><b>25.2</b></a><ul><li><em>Section 7.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3744.4">16</a></li></ul></li><li><em>RFC3864</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3864.1">21.3</a>, <a href="#RFC3864"><b>25.2</b></a></li><li><em>RFC3986</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.1">3</a>, <a href="#rfc.xref.RFC3986.2">3</a>, <a href="#rfc.xref.RFC3986.3">4.4</a>, <a href="#rfc.xref.RFC3986.4">5.1</a>, <a href="#rfc.xref.RFC3986.5">8.3</a>, <a href="#rfc.xref.RFC3986.6">8.3</a>, <a href="#rfc.xref.RFC3986.7">8.3</a>, <a href="#rfc.xref.RFC3986.8">8.3</a>, <a href="#rfc.xref.RFC3986.9">8.3</a>, <a href="#rfc.xref.RFC3986.10">8.3.1</a>, <a href="#rfc.xref.RFC3986.11">10.1</a>, <a href="#rfc.xref.RFC3986.12">10.3</a>, <a href="#RFC3986"><b>25.1</b></a>, <a href="#rfc.xref.RFC3986.13">C</a><ul><li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.10">8.3.1</a></li><li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.2">3</a>, <a href="#rfc.xref.RFC3986.7">8.3</a>, <a href="#rfc.xref.RFC3986.13">C</a></li><li><em>Section 3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.8">8.3</a></li><li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.6">8.3</a>, <a href="#rfc.xref.RFC3986.11">10.1</a>, <a href="#rfc.xref.RFC3986.12">10.3</a></li><li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.5">8.3</a></li></ul></li><li><em>RFC4122</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4122.1">6.5</a>, <a href="#rfc.xref.RFC4122.2">20.7</a>, <a href="#rfc.xref.RFC4122.3">20.7</a>, <a href="#rfc.xref.RFC4122.4">20.7</a>, <a href="#RFC4122"><b>25.1</b></a>, <a href="#rfc.xref.RFC4122.5">C</a><ul><li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4122.5">C</a></li><li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4122.3">20.7</a>, <a href="#rfc.xref.RFC4122.4">20.7</a></li></ul></li></ul></li><li><a id="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul><li>set&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.14.26">14.26</a></li></ul></li><li>shared&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.14.27">14.27</a></li></ul></li><li>State Token&nbsp;&nbsp;<a href="#rfc.iref.s.1"><b>3</b></a></li><li>status&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.14.28">14.28</a></li></ul></li><li>Status Codes&nbsp;&nbsp;<ul><li>102 Processing&nbsp;&nbsp;<a href="#rfc.iref.s.2">21.4</a></li><li>207 Multi-Status&nbsp;&nbsp;<a href="#rfc.section.11.1"><b>11.1</b></a></li><li>412 Precondition Failed&nbsp;&nbsp;<a href="#rfc.section.12.1">12.1</a></li><li>414 Request-URI Too Long&nbsp;&nbsp;<a href="#rfc.section.12.2">12.2</a></li><li>422 Unprocessable Entity&nbsp;&nbsp;<a href="#rfc.section.11.2"><b>11.2</b></a></li><li>423 Locked&nbsp;&nbsp;<a href="#rfc.section.11.3"><b>11.3</b></a></li><li>424 Failed Dependency&nbsp;&nbsp;<a href="#rfc.section.11.4"><b>11.4</b></a></li><li>507 Insufficient Storage&nbsp;&nbsp;<a href="#rfc.section.11.5"><b>11.5</b></a></li></ul></li></ul></li><li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul><li>timeout&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.14.29">14.29</a></li></ul></li><li>Timeout header&nbsp;&nbsp;<a href="#rfc.section.10.7"><b>10.7</b></a></li></ul></li><li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul><li>UNLOCK method&nbsp;&nbsp;<a href="#rfc.section.9.11"><b>9.11</b></a></li><li>URI&nbsp;&nbsp;<a href="#rfc.iref.u.1"><b>3</b></a></li><li>URI Mapping&nbsp;&nbsp;<a href="#rfc.iref.u.3"><b>3</b></a></li><li>URI scheme&nbsp;&nbsp;<ul><li>DAV&nbsp;&nbsp;<a href="#rfc.iref.u.5"><b>21.1</b></a></li><li>opaquelocktoken&nbsp;&nbsp;<a href="#rfc.section.C"><b>C</b></a></li></ul></li><li>URL&nbsp;&nbsp;<a href="#rfc.iref.u.2"><b>3</b></a></li><li>URL Mapping&nbsp;&nbsp;<a href="#rfc.iref.u.4"><b>3</b></a></li></ul></li><li><a id="rfc.index.W" href="#rfc.index.W"><b>W</b></a><ul><li>write&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.14.30">14.30</a></li></ul></li></ul></li></ul></div></section><section id="rfc.authors" class="avoidbreakinside"><h2><a href="#rfc.authors">Author's Address</a></h2><address><b>Lisa Dusseault</b>
      (editor)
    <br>CommerceNet<br>2064 Edgewood Dr.<br>Palo Alto, CA&nbsp;94303<br>US<br>Email: <a href="mailto:ldusseault@commerce.net">ldusseault@commerce.net</a></address></section><section id="rfc.copyright"><h2><a href="#rfc.copyright">Full Copyright Statement</a></h2><p>Copyright © The IETF Trust (2007).</p><p>This
 document is subject to the rights, licenses and restrictions contained 
in BCP 78, and except as set forth therein, the authors retain all their
 rights.</p><p>This document and the information contained herein are 
provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION 
HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 
RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 
PARTICULAR PURPOSE.</p></section><section id="rfc.ipr"><h2><a href="#rfc.ipr">Intellectual Property</a></h2><p>The
 IETF takes no position regarding the validity or scope of any 
Intellectual Property Rights or other rights that might be claimed to 
pertain to the implementation or use of the technology described in this
 document or the extent to which any license under such rights might or 
might not be available; nor does it represent that it has made any 
independent effort to identify any such rights. Information on the 
procedures with respect to rights in RFC documents can be found in BCP 
78 and BCP 79.</p><p>Copies of IPR disclosures made to the IETF 
Secretariat and any assurances of licenses to be made available, or the 
result of an attempt made to obtain a general license or permission for 
the use of such proprietary rights by implementers or users of this 
specification can be obtained from the IETF on-line IPR repository at <a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.</p><p>The
 IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary rights 
that may cover technology that may be required to implement this 
standard. Please address the information to the IETF at <a href="mailto:ietf-ipr@ietf.org">ietf-ipr@ietf.org</a>.</p></section><section id="n-acknowledgement"><h2><a href="#n-acknowledgement">Acknowledgement</a></h2><p>Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).</p></section>
</body></html>